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Abstract 

We present verification methods for iogic programs witli deiay deciarations. Tlie verified 
properties are termination and freedom from errors related to built-ins. Concerning ter- 
mination, we present two approaclies. The first approach tries to eliminate the well-known 
problem of speculative output bindings. The second approach is based on identifying the 
predicates for which the textual position of an atom using this predicate is irrelevant with 
respect to termination. Three features are distinctive of this work: it allows for predicates 
to be used in several modes; it shows that block declarations, which are a very simple 
delay construct, are sufficient to ensure the desired properties; it takes the selection rule 
into account, assuming it to be as in most Prolog implementations. The methods can be 
used to verify existing programs and assist in writing new programs. 

Note: This paper will be published in Theory and Practice of Logic Programming. 



1 Introduction 

The standard selection rule in logic programming states that the leftmost atom 
in a query is selected in each derivation step. However, there are some applica- 
tions for which this rule is inappropriate, e.g. multiple modes, the test-and-generate 



paradigm ( Naish, 1992 ) or parallel execution ( Apt fc Luitjes, 1995 ). To allow for 



more user-defined control, several logic programming languages provide delay dec- 



larations ( Hill fc Lloyd, 1994 ; SICStus, 1998 ). An atom in a query is selected for 
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resolution only if its arguments are instantiated to a specified degree. This is es- 
sential to ensure termination and to prevent runtime errors produced by built-in 
predicates [huilt-ins). 

In this paper we present methods for verifying programs with delay declara- 
tions. We consider two aspects of verification: Programs should terminate, and 
there should be no type or instantiation errors related to the use of built-ins. 

Three distinctive features of this work make its contribution: (a) it is assumed 
that predicates may run in more than one mode; (b) we concentrate on block 
declarations, which are a particularly simple and efficient delay construct; (c) the 
selection rule is taken into account. We now motivate these features. 

(a) Allowing predicates to run in more than one mode is one application of 
delay declarations. Although other authors ( Apt fc Luitjes, 1995 ; Naish, 199^ ) have 
not explicitly assumed multiple modes, they mainly give examples where delay 
declarations are clearly used for that purpose. Whether allowing multiple modes 
is a good approach or whether it is better to generate multiple versions of each 
predicate ( Somogyi et ai, 1996 ) is an ongoing discussion ( Hill, 1998 ). Our theory 
allows for multiple modes, but of course this does not exclude other applications of 
delay declarations. 

(b) The block declarations declare that certain arguments of an atom must 
be non-variable before that atom can be selected for resolution. Insufficiently in- 
stantiated atoms are delayed. As demonstrated in SICStus (SICStus, 1998), block 
declarations can be efficiently implemented; the test whether arguments are non- 
variable has a negligible impact on performance. Therefore such constructs are the 
most frequently used delay declarations. Note that most results in this paper also 
hold for other delay declarations considered in the literature. This is discussed in 
Sec. |. 

(c) Termination may critically depend on the selection rule, that is the rule which 
determines, for a derivation, the order in which atoms are selected. We assume that 
derivations are left-based. These are derivations where (allowing for some exceptions 
concerning the execution order of two literals woken up simultaneously) the leftmost 
selectable atom is selected. This is intended to model derivations in the common 
implementations of Prolog with block declarations. Other authors have avoided 



the issue by abstracting from a particular selection rule (Apt & Luitjes, 1995 



Liittringhaus-Kappel, 1993); considering left-based selection rules on a heuristic 
basis (Naish, 1992); or making the very restrictive assumption of local selection 
rules ( [Marchiori fc Teusink, 1999| ). 

The main contribution concerns termination. We have isolated some of the causes 
of non-termination that are related to the use of delay declarations and identi- 
fied conditions for programs to avoid those causes. These conditions can easily 
be checked at compile-time. The termination problem for a program with delay 
declarations is then translated to the same problem for a corresponding program 
executed left-to- right. It is assumed that, for the corresponding program, termina- 



tion can be shown using some existing technique (Apt, 1997; De Schreye & Decorte 



1994; Etalle et ai, 1999). 



One previously studied cause of non-termination associated with delay declara- 
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tions is speculative output bindings ( Naish, 1992| ). These are bindings made before it 
is known that a solution exists. We present two complementing methods for dealing 
with this problem and thus proving (or ensuring) termination. Which method must 
be applied will depend on the program and on the mode being considered. The first 
method exploits that a program does not use any speculative bindings, by ensuring 
that no atom ever delays. The second method exploits that a program does not 
make any speculative bindings. 

However, these two methods are quite limited. As an alternative approach to 
the termination problem, we identify certain predicates that may loop when called 
with insufficient (that is, non-variable but still insufRciently instantiated) input. 
For instance, with the predicate permute/2 where the second argument is input, 
the query permute (A , [1 1 B] ) has insufficient input and loops.Q However, the query 
permute (A, [1,2]) has sufficient input and terminates. The idea for proving ter- 
mination is that, for such predicates, calls with insufficient input must never arise. 
This can be ensured by appropriate ordering of atoms in the clause bodies. This 
actually works in several modes provided not too many predicates have this unde- 
sirable property. 

Our work on built-ins focuses on arithmetic built-ins. By exploiting the fact 
that for numbers, being non-variable implies being ground, we show how both 
instantiation and type errors can be prevented. 

Finally, we consider two other issues related to delay declarations. First, we iden- 
tify conditions so that certain block declarations can be omitted without affecting 
the runtime behaviour. Secondly, to verify programs with delay declarations, it is 
often necessary to impose a restriction on the modes that forbids tests for iden- 
tity between the input arguments of an atom. We explain how this rather severe 
restriction is related to the use of delay declarations and how it can be weakened. 

This paper is organised as follows. The next section defines some essential con- 
cepts and notations. Section ^ introduces four concepts of "modedness" and "typed- 
ness" that are needed later. Section ^, which is based on previously published 
work ( Smaus et ai, 1999D , presents the first approach to the termination problem. 
Section |^, which is also based on previously published work (Smaus et aL, 1998), 
presents the second approach. Section |^ is about errors related to built-ins. Sec- 
tion ^ considers ways of simplifying the block declarations. Section ^ investigates 
related work. Section |^ concludes with a summary and a look at ongoing and future 
work. 



2 Essential Concepts and Notations 
2.1 Standard Notions 



We base the notation on (Apt & Luitjes, 1995; Lloyd, 1987). For the examples we 
use SICStus notation (SICStus, 1998). A term u occurs directly in a vector of 
terms t if u is one of the terms of t. (For example, a occurs directly in (a, b) but 



^ The program for permut6/2 is given in Fig. 
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not in (/(a), b).) We also say that u fills a position in t. To refer to the predicate 
symbol of an atom, we say that an atom p{. . .) is an atom using p. The set of 
variables in a syntactic object o is denoted by vars{o). A syntactic object is linear 
if every variable occurs in it at most once. Otherwise it is non-linear. A flat term 
is a variable or a term f{xi, . . . , a;„), where n > and the Xi are distinct variables. 
The domain of a substitution a is dom{a) — {x \ xa ^ x}. The variables in the 
range of a are denoted as ran{a) ~ {y \ y vars{xa), y ^ x}. 

A query is a finite sequence of atoms. Atoms are denoted by a, b, h, queries by 
B, F, H, Q, R. Sometimes we say "atom" instead of "query consisting of an atom" . 
A derivation step for a program P is a pair {Q, 6); {R, da), where Q — Qi,a,Q2 
and R = Qi,B,Q2 are queries; is a substitution; a an atom; /i <— a variant of a 
clause in P, renamed apart from QO, and a the most general unifier (MGU) of aO 
and h. We call a9 (or a)^ the selected atom and ROa the resolvent of Q6 and 
B. 

A derivation ^ for a program P is a sequence (Qoj ^o); {Qi, . . . where each 
pair {Qi,Oi)] {Qi+i,Oi^i) in ^ is a derivation step for P. Alternatively, we also say 
that ^ is a derivation of P U {Qo^o}- We also denote ^ by Qo^o; Qi^i; ■ • ■• A 
derivation is an LD-derivation if the selected atom is always the leftmost atom 
in a query. 

If F, a, H\ {F, B, H)9 is a step in a derivation, then each atom in B9 (or B)^ 
is a direct descendant of a, and bO (or 5)^ is a direct descendant of h for 
all h in P, H . We say that 5 is a descendant of a, or a is an ancestor of 6, if 
(6, a) is in the reflexive, transitive closure of the relation is a direct descendant. The 
descendants of a set of atoms are defined in the obvious way. Consider a derivation 
Qo! ■ • ■ ; Qi] • • ■ ; Qj') Qj+i] ■ ■ ■■ We call Qj] Qj+i an a-step if a is an atom in Qi 
[i ^ j) and the selected atom in Qj; Qj+i is a descendant of a. 

2.2 Modes 

For a predicate p/n, a mode is an atom p{mi, . . . ,m„), where uii G {/, 0} for 
I G {1, . . . ,n}. Positions with / are called input positions, and positions with O 
are called output positions of p. A mode of a program is a set of modes, one 
mode for each of its predicates. An atom written as p(s,t) means: s and t are the 
vectors of terms filling the input and output positions of p, respectively. 

An atom p(s, t) is input-linear if s is linear. A clause is input-linear if its head 
is input-linear. A program is input-linear if all of its clauses are input-linear and 
it contains no uses of =(/, 

We claim that the techniques we describe are suitable for programs that can run 
in several modes. Throughout most of the presentation, this is not explicit, since 
we always consider one mode at a time. Therefore, whenever we refer to the input 
and output positions, this is always with respect to one particular mode. However, 
we will see in several examples that one single program can be "mode correct" , in a 

Whether or not the substitution has been applied is always clear from the context. 
^ Conceptually, one can think of each program containing the fact clause X = X. 
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well-defined sense, with respect to several different modes. In particular, one single 
delay declaration for a predicate can allow for this predicate to be used in different 
modes. 



This is different from the assumption made by some authors (Apt & Etalle, 1993 



Apt & Luitjes, 1995; Etalle et ai, 1999; Naish, 1992) that if a predicate is to be 
used in several modes, then multiple (renamed) versions of this predicate should 
be introduced, which may differ concerning the delay declarations and the order of 
atoms in clause bodies. 

Note that our notion of modes could easily be generalised further by assigning a 
mode to predicate occurrences rather than predicates (Smaus, 1999). 



2.3 Types 



A type is a set of terms closed under instantiation (Apt fc Luitjes, 1995; Boye, 



1996 ). The variable type is the type that contains variables and hence, as it is 
closed under instantiation, all terms. Any other type is a non-variable type. A 
type is a ground type if it contains only ground terms. A type is a constant type 
if it is a ground type that contains only (possibly infinitely many) constants. In the 
examples, we use the following types: any is the variable type, list the non- variable 
type of (nil-terminated) lists, int the constant type of integers, il the ground type 
of integer lists, num the constant type of numbers, nl the ground type of number 
lists, and finally, tree is the non- variable type defined by the context-free grammar 
{tree — > leaf; tree — > node(tree, any, tree)}. 

We write i : T for "t is in type T". We use S, T to denote vectors of types, 
and write |= s : S t : T if for all substitutions a, sa : S implies tcr : T. It 
is assumed that each argument position of each predicate p/n has a type associ- 
ated with it. These types are indicated by writing the atom p{Ti, . . . ,Tn) where 
Ti, . . . ,T„ are types. The type of a program P is a set of such atoms, one for 
each predicate defined in P. An atom is correctly typed in a position if the term 
filling this position has the type that is associated with this position. A term t is 



type-consistent with respect to T (Deransart & Maluszyiiski, 199S) if there is 



a substitution 6 such that t9 : T. A term t occurring in an atom in some position is 
type-consistent if it is type-consistent with respect to the type of that position. 



2.4 block Declarations 



A block declaration ( SICStus, 1998 ) for a predicate p/n is a (possibly empty) set of 
atoms each of which has the form p(6i, . . . , bn), where bi £ {?, -} for i S {1, . . . , n}. 
A program consists of a set of clauses and a set of block declarations, one for each 
predicate defined by the clauses. If P is a program, an atom p{ti, . . . , t„) is blocked 
in P if there is an atom p{bi, . . . , 6„) in the block declaration for p such that for 
all i e {1, ... ,71} with bi ~ -, we have that ti is variable. An atom is selectable 
in P if it is not blocked in P. 



Example 2.1 
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Consider a program containing the block declaration 
:- block append(- , ? , -) , appendC? , - , -) . 

Then atoms append(X, Y, Z), append([l|X], Y, Z), and append(X, [2|Y],Z) are blocked 
inP, whereas atoms append([l|X], [2|Y], Z), append(X, Y, [1|Z]) and append(X, [2|Y], [1|Z]) 
are selectable in P. 

Note that equivalent delay constructs are provided in several logic programming 
languages, although there may be differences in the syntax. 

A delay-respecting derivation for a program P is a derivation where the 
selected atom is always selectable in P. We say that it flounders if it ends with a 
non-empty query where no atom is selectable. 



2.5 Left-based Derivations 

We now formalise the sort of derivations that arise in practice using almost any 
existing Prolog implementations. Some authors have considered a selection rule 



stating that in each derivation step, the leftmost selectable atom is selected (Apt 



Luitjes, 1995; Boye, 1996; Naish, 1992| ). We are not aware of an existing language 



that uses this selection rule, contradicting Boye's claim (1996, page 123) that sev- 



eral modern Prolog implementations and even Godel (Hill & Lloyd, 1994) use this 
selection rule. In fact, Prolog implementations do not usually guarantee the order 
in which two simultaneously woken atoms are selected. 

Definition 2.2 

[left-based derivation] Consider a delay-respecting derivation Qo', . . . ] Qf, . . where 
Qi = Ri,R2, and Pi contains no selectable atom. Then every descendant of every 
atom in Pi is waiting. A delay-respecting derivation Qo;Qi . . . is left-based if for 
each step Qi] Qi+i, the selected atom is either waiting in Qi, or it is the leftmost 
selectable atom in Qi. 



Example 2.3 

Consider the following program: 

:- block a(-) . :- block b(-) 

a(l) . b(X) :- b2(X) . 



c(l). b2(l). d. 

The following is a left-based derivation. Waiting atoms are underlined. 

a(X),b(X),c(X),d; a(l),b(l),d; a(l) , b2(l) , d; a(l),d; d; □. 

Note that b(l) and b2(l) are waiting and selectable, and therefore they can be 
selected although there is the selectable atom a(l) to the left. < 

We do not believe that it would be useful or practical to try to specify the selection 
rule precisely, but from our research, it appears that derivations in most Prolog 
implementations are left-based. 
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Note that the definition of left-based derivations for a program and query de- 
pends both on the textual order of the atoms in the query and clauses and on the 
block declarations. In order to maintain the textual order while considering dif- 
ferent orders of selection of atoms, it is often useful to associate, with a query, a 
permutation tt of the atoms. 

Let TT be a permutation on {1, . . . , n}. We assume that 7r(«) = « for i ^ {1, . . . , n}. 
In examples, tt is written as (7r(l), . . . , 7r(n)). We write 7r(oi, . . . , o„) for the appli- 
cation of vr to the sequence oi, . . . , o„, that is o^-i(i), . . . , o^-i(„). 



3 Correctness Conditions for Verification 



Apt and Luitjes ( 1995 ) consider three correctness conditions for programs: nicely 



moded, well typed, and simply moded. Apt (1997) and Boye ( 1996 ) propose a gener- 
alisation of these conditions that allows for permutations of the atoms in each query. 
Such correctness conditions have been used for various verification purposes: occur- 



check freedom, flounder freedom, freedom from errors related to built-ins (Apt 



Luitjes, 1995), freedom from failure (Bossi fc Cocco, 1999), and termination (Etallc 



et ai, 199£). In this section we introduce four such correctness conditions and show 



some important statements about them. The correctness conditions will then be 
used throughout the paper. 

The idea of these correctness conditions is that in a query, every piece of data 
is produced (output) before it is consumed (input), and every piece of data is 
produced only once. The definitions of these conditions have usually been aimed at 
LD-derivations, which means that an output occurrence of a variable must always 
be to the left of any input occurrence of that variable. 



3.1 Permutation Nicely Moded Programs 

In a nicely moded query, a variable occurring in an input position does not occur 
later in an output position, and each variable in an output position occurs only 
once. We generalise this to permutation nicely moded. Note that the use of the 
letters s and t is reversed for clause heads. We believe that this notation naturally 
reflects the data flow within a clause. This will become apparent in Def. 

Definition 3.1 

[permutation nicely moded] Let Q — pi(si, ti), . . . ,p„(s„, t„) be a query and tt 
a permutation on {1, . . . , n}. Then Q is 7r-nicely moded if ti, . . . , t„ is a linear 
vector of terms and for all i G {1, . . . , 71} 

vars{si) n [J vars{tj) = 0. 

7r(i)<7r(j)<n 

The query 7r(Q) is a nicely moded query corresponding to Q. 

The clause C = p(to, s„+i) <— Q is 7r-nicely moded if Q is 7r-nicely moded and 

n 

vars(tf^) n vars{tj) = 0. 
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:- block permute(-,-) . :- block delete(? ,- ,-) , 

permute ([],[]). delete (X , [X I Z] , Z) . 

permuteCUlX] ,Y) :- delete (X, [Ul Y] , [Ul Z] ) 
permute (X, Z) , delete(X,Y,Z) . 



delete(U,Y,Z) . 



Ml = {permute(/, 0),delete(/, 0,1)} 
M2 = {permute(0, /),delete(0, /, O)} 



Figure 1. The permute program 



The clause p{to, s„+i) ^ tt{Q) is a nicely moded clause corresponding to C. 

A query (clause) is permutation nicely moded if it is 7r-nicely moded for 
some TT. A program P is permutation nicely moded if aU of its clauses are. A 
nicely moded program corresponding to P is a program obtained from P by 
replacing every clause C in P with a nicely moded clause corresponding to C. <l 



In Lemma 3.3, on which many results of this paper depend, we require a program 



not only to be permutation nicely moded, but also input-linear (see Subsec. 2.2) 



Example 3.2 

The program in Fig. |^ is nicely moded and input-linear in mode Mi.^ In mode 
M2 it is permutation nicely moded and input-linear. In particular, the second 
clause for permute is (2, l)-nicely moded. In "test mode", that is, {permute(/, /), 
delete(/, /, 0)}, it is permutation nicely moded, but not input-linear, because the 
first clause for delete is not input-linear. < 

We show that there is a persistence property for permutation nicely-modedness 



similar to that for nicely-modedness ( Apt fc Luitjes, 1995 ) 



Lemma 3.3 

Let Q = ai, . . . , a„ be a 7r-nicely moded query and C = ft- ^ 61, . . . , 6„i be a p- 
nicely moded, input-linear clause where vars{Q) D vars{C) ~ 0. Suppose for some 
A:€{l,...,7i},/i and are unifiable. Then the resolvent of Q and C with selected 
atom ttk is p-nicely moded, where the derived permutation p on {1, ... , n+m — 1] 
is defined by Q[i) — 

7r(i) ii i < k, TT(i) < TT{k) 

7r(i) + TO — 1 if i < k, 7r(i) > TT{k) 

n{k) + p{i - k + I) - 1 ifk<i<k + m 

7r(i — TO + 1) if k + m < i < n + m, n{i — to + 1) < n{k) 

7r(i — TO + 1) + TO — 1 if fc + TO < i < n + m, 7r(i — to -f 1) > 7r(fc). 

Proof 



For convenient reference, the modes are included in the figure. Also, the program contains 
block declarations. We will refer to those later; they should be ignored for the moment. 
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Let be the MGU of h and afe. By Def. p.l| , we have that a^-i(i), . . . , a^-i(„ 



and h 

Lemma 11 (Apt & Luitjes, 1995) 



are nicely moded and h is input-linear. Thus by 



(a7r-i(l), • ■ ■ , a7r-i(7r(fc)-l), ^p-i(l)' ' • ■ ' ^p-l (^m) , O-tt-i (Tr{k) + 1) , ■ ■ ■ , a7r-i(n)) ^ 

is nicely moded, and hence (ai, . . . , Uk-i, 61, ... , 6m, Ofc+i, . . . , a„) ^ is nicely moded. 
□ 

Figure 1^ illustrates g when Q — 01,02,03,04, tt = (4, 3, 1, 2) , C — /i ^ 61,62, 
/3 = (2,1), and k = 2. Thus ^? = (5,4,3,1,2). Observe that, at each step of a 
derivation, the relative order of atoms given by the derived permutation is preserved. 
By a straightforward induction on the length of a derivation, using the definition 
of g for the base case, we obtain the following corollary. 

Corollary 3.4 

Let P be a permutation nicely moded, input-linear program, Q = oi, . . . , a„ be a 
TT-nicely moded query and i,j G {1, . . . , n} such that 7r(i) < 7r(j'). Let Q; . . . ; i? be 
a derivation for P and suppose i? = 61, . . . , is p-nicely moded. If for some fc, Z G 
{1, . . . , m}, 6fc is a descendant of o.^ and 6; is a descendant of Oj, then p{k) < p{l). 

Note that derivations of a permutation nicely moded query and a permutation nicely 
moded, input-linear program are occur-check free. This is is a trivial consequence 



of Thm. 13 ( Apt fc Luitjes, 1995 ). In Subsec. 7^, we discuss ways in which the 
condition of input-linearity in Lemma 3.3 can be weakened. 



3.2 Permutation Well Typed Programs 



In a well typed query (Apt & Luitjes, 1995; Apt & Pellegrini, 1994; Bronsard et al 



1992), the first atom is correctly typed in its input positions. Furthermore, given a 
well typed query Q, a, Q' and assuming LD-derivations, if Q is resolved away, then 
o becomes correctly typed in its input positions. We generalise this to permuta- 



tion well typed (previously called properly typed (Apt, 1997)). As with the modes, 
we assume that the type associated with each argument position is given. In the 
examples, the types will be the natural ones that would be expected. 



Definition 3.5 

[permutation well typed] Let Q 
is the type of pi for each i S {1, 



:pi(Sl,tl), . . . a query, where Pi{Si, T^) 

. . , n}. Let TT be a permutation on {1, . . . , n}. Then 
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, n} and L = 1 

Si '. Si 



(1) 



Q is TT-well typed if for alH G {1, . 

H( A 

L<7r0)<7r(i) 

The clause p(to, s„+i) ^ Q, where p{Tq, S„+i) is the type of p, is 7r-well typed if 
@) holds for alH e {1, . . . , n + 1} and i = 0. 

A permutation well typed query (clause, program) and a well typed query 
(clause, program) corresponding to a query (clause, program) are defined in 
analogy to Def. 3.1. <1 



Example 3.6 

Consider the program in Fig. ^ with type {permute(nsi, Zisi), 
d.e\et,e[any^li stylist)}. It is well typed for mode Mi, and permutation well 



typed for mode M2, with the same permutations as in Ex. 3.2. The same holds 
assuming type {permute(7iZ, nZ), de\ete{num^nl^nl)}. <\ 

Permutation well-typedness is also a persistent condition. The proof is analogous 
to Lemma p?^, but using Lemma 23 instead of Lemma 11 (Apt & Luitjes, 1995). 



Lemma 3. 7 

Let Q = ai, . . . ,an he a 7r-well typed query and C — <— 61, . . . , 6^ be a p-well 
typed clause where vars{Q) n vars{C) = 0. Suppose for some fee {1, . . . , n}, h and 
Ofc are unifiable. Then the resolvent of Q and C with selected atom is g-well 



typed, where g is the derived permutation (see Lemma 3.2) 



Generalising Thm. 26 (Apt & Luitjes, 1995), permutation well-typedness can be 



used to show that derivations do not flounder (Smaus, 1999) 



3.3 Permutation Simply Typed Programs 

We now define permutation simply-typedness. The name simply typed is a combina- 



tion of simply moded (Apt & Luitjes, 1995) and well typed. In a permutation simply 



typed query, the output positions are filled with variables, and therefore they can 
always be instantiated so that all atoms in the query are correctly typed. 

Definition 3.8 

[permutation simply typed] Let Q = pi(si,ti), . . . ,p„(s„,t„) be a query and tt a 
permutation on {1, . . . , n}. Then Q is 7r-simply typed if it is 7r-nicely moded and 
TT-well typed, and ti, . . . , t„ is a vector of variables. 

The clause p(to, s„-|_i) ^ Q is 7r-simply typed if it is tt- nicely moded and 7r-well 
typed, ti, . . . , t„ is a vector of variables and to is a vector of flat type-consistent 
terms that has a variable in each position of variable type. 

A permutation simply typed query (clause, program) and a simply typed 
query (clause, program) corresponding to a query (clause, program) are defined 



in analogy to Def. B.l. < 



Example 3.9 
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:- block qsort (-,-). 
qsort ([],[]). 
qsort([X|Xs] ,Ys) :- 

append(As2, [X|Bs2] ,Ys) , 

part(Xs,X,As,Bs) , 

qsort (As , As2) , 

qsort (Bs,Bs2) . 

:- block append(- , ? , -) . 
append ([] ,Y,Y). 
append ( [X I Xs] , Ys , [X I Zs] ) 
append (Xs,Ys,Zs) . 



:- block parte?,-,?,?) , 
parte-,?,-,?) , 
parte-,?,?,-) . 
partCD, _,[],[]). 
parte [XlXs] ,C, [X I As] ,Bs) :- 

leqex,C), 

part eXs ,C , As ,Bs) . 
parteCXiXs] ,C,As, [X|Bs]) :- 

grtex,C), 

parteXs,C,As,Bs) . 

:- block leqe?,-), leqe-,?), 
leqeA,B) :- A =< B. 

:- block grte?,-), grte-,?). 
grteA,B) :- A > B. 



A'/i = {qsort(/, 0),append(/,/, O), leq(/, /), grt(/, /), part(/, /, O, O)} 
M2 = {qsort (0,/),append(0, O, /), leq(/, /), grt(/, /), part(0, /, /, /)} 



Figure 3. The quicksort program 



Figure^ shows a version of the quicksort program. Assume the type {qsort (nZ, nl), 
append(n/, n/, nl), leq{num, num), grt(num, num), part(n/, num, rd, nl)}. The pro- 
gram is permutation simply typed for mode Mi . It is not permutation simply typed 
for mode M2, due to the non-variable term [X|Bs2] in an output position. <] 



The persistence properties stated in Lemmas p.3| and 3/7 are independent of the 
selectability of an atom in a query. For permutation simply typed programs, this 
persistence property only holds if the selected atom is sufRciently instantiated in 
its input arguments. This motivates the following definition. 

Definition 3.10 

[bound/free] Let P be a permutation well typed program. An input position of a 
predicate p in P is bound if there is a clause head p{. . .) in P that has a non- 
variable term in that position. An output position of a predicate p in P is bound 
if there is an atom p(. . .) in a clause body in P that has a non- variable term in that 
position. A position is free if it is not bound. 

We denote the projection of a vector of arguments r onto its free positions as r^, 
and onto its bound positions as r'^. <\ 

Note that for a permutation simply typed program, there are no bound output 
positions, and bound input positions must be of non- variable type. 

Lemma 3.11 

Let Q =pi(si,ti), . . . ,p„(s„,t„) be a TT-simply typed query and C = pfc(vo,u„+i) ^ 

) a /9-simply typed, input-hnear clause where vars{C) D 
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vars{Q) — 0. Suppose that for some k £ {1, . . . , n}, is non-variable in all bound 
input positions^ and 9 is the MGU of pfc(s/j,tfc) and Pki^o, Um+i)- Then 

1. there exist substitutions 9i, 62 such that 6 — 6162 and 

(a) wq6i = Sk and dom{9i) C tiars(vo), 

(b) tk62 = u„i+i0i and dom{92) Q vars{tk); 

2. dom{9) C vars{tk) U wars(vo); 

3. dom{6) n vars{ti, . . . ,tfe_i, vi, . . . ,v„,tfe+i, . . . ,t„) = 0; 

4. the resolvent of Q and C with selected atom pk{sk,tk) is p-simply typed, 
where g is the derived permutation (see Lemma ^^)- {Proof see Appendix) 

The following corollary of Lemma 3.11 (^) holds since by Def. 3^, the leftmost 
atom in a simply typed query is non-variable in its input positions of non-variable 
type. 

Corollary 3.12 

Every LD-resolvent of a simply typed query Q and a simply typed, input-linear 
clause C, where vars{C) fl vars{Q) = 0, is simply typed.^ 

Before studying permutation simply typed programs any further, we now introduce 
a generalisation of this class. 



3.4 Permutation Robustly Typed Programs 

The program in Fig. ^ is not permutation simply typed in mode M2, due to the 
non- variable term [X I Bs2] in an output position. It has been acknowledged previ- 
ously that it is difficult to reason about queries where non- variable terms in output 
positions are allowed, but on the other hand, there are natural programs where this 



occurs dApt fc Etalle, 19931) . 

We define permutation robustly-typedness, which is a carefully crafted extension 
of permutation simply-typedness, allowing for non-variable but flat terms in out- 
put positions. It has been designed so that a persistence property analogous to 



Lemmas 3.3, 3.7 and 3.11 holds 



Definition 3.13 

[permutation robustly typed] Assume a permutation well typed program P where 
the bound positions are of non-variable type. Let Q — pi(si,ti), . . . ,p„(s„,t„) be 
a query (using predicates from P) and tt a permutation on {1, . . . ,n}. Then Q is 
TT-robustly typed if it is 7r-nicely moded and 7r-well typed, t^. 



t!, is a vector 



of variables, and t^, . 

The clause p(to, 
typed; 



, t„ is a vector of flat type-consistent terms. 



Q is TT-robustly typed if it is 7r-nicely moded; 7r-well 



1995) 



3 is similar to the assumption "the delay declarations imply matching" (A.pt & Luitjcs 



" This even holds without requiring C to be input-linear (Smaus, 1 99 9, T;n nirna 7.3), but here we 
do not need the stronger result, and it is not a corollary of Lemma 5.11 (W). 
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:- block treeList (- , -) . 

treeList (leaf , [] ) . 

treeList (node (L, Label, R) .List) :- 

append(LList , [Label I RList] ,List) , 

treeList(L,LList) , 

treeList (R, RList) . 



:- block append(- , ? , -) . 
append ( [] ,Y,Y) . 
append ( [X I Xs] , Ys , [X I Zs] ) 
append(Xs , Ys , Zs) . 



Ml = {treeList(/, O), append(/, /, O)} 
M2 = {treeList(0, /),append(0, 0,1)} 



Figure 4. Converting trees to lists or vice versa 



1. tg,...,t^ is a vector of variables, and to,...,t^ is a vector of flat type- 
consistent terms; and 

2. if a position in s^j^i of type r is filled with a variable x, then x also fills a 
position of type r in tg, . . . , t^. 



A permutation robustly typed query (clause, program) and a robustly typed 

query (clause, program) corresponding to a query (clause, program) are defined 



in analogy to Def. 3.1. < 



Note that any permutation simply typed program is permutation robustly typed 
in which all output positions are free. 

Example 3.14 

Recall the program in Fig. ^. It is permutation robustly typed in mode M2, and 
the second position of append is the only bound output position. Note in particular 



that Condition g of Dcf. 3.13 is met for the recursive clause of append: the variable 
Ys fills an output position of the head and also an output position of the body. 
Moreover, the program is trivially permutation robustly typed in mode Mi. 

Example 3.15 

The program in Fig. |^ converts binary trees into lists and vice versa. Assuming type 
{treeList(tree, list), append(/ist, list, list)}, the program is permutation robustly 
typed in mode M2, and the second position of append is the only bound output po- 
sition. It is also permutation robustly typed in mode Mi , where all output positions 
are free. < 

The following lemma shows a persistence property of permutation robustly- typedness, 
and shows, furthermore, that a derivation step cannot instantiate the input argu- 
ments of the selected atom. 

Lemma 3.16 

Let Q = pi(si, ti), . . . ,p„(s„, t„) a TT-robustly typed query and C = Pfe(vo, u^+i) ^ 
q'i(ui, Vi), . . . , (7m(um, Vm) a p-robustly typed, input-linear clause where vars{Q) D 
vars{C) = 0. Suppose that for some k G {1, . . . ,n}, Pk{sk,'tk) is non- variable in all 
bound input positions and 9 is the MGU of pk{sk,tk) and pfe(vo, u^+i). 
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Then the resolvent of Q and C with selected atom pk{sk,tk) is ^?-robustly typed, 



where g is the derived permutation (see Lemma 3.3). Moreover dom{9)nvars{sk) = 
0. (Proof see Appendix) 

We now define programs where the block declarations fulfill a natural minimum 
and maximum (^) requirement. The minimum requirement states that selected 
atoms must fulfill the assumption of Lemmas 3.11 and 3.16. The maximum require- 



ment is needed in Subsec. 5.2. In other words, we define programs where the "static" 



concept of modes and the "dynamic" concept of block declarations correspond in 
the natural way. 

Definition 3.17 

[input selectability] Let P be a permutation robustly typed program. P has input 
selectability if an atom using a predicate in P that has variables in all free output 
positions is selectable in P 

1. only if it is non- variable in all bound input positions; and 

2. if it is non- variable in all input positions of non- variable type. 



Note that the above definition is aimed at atoms in permutation robustly typed 
queries, since these atoms have variables in all free output positions. 

Example 3.18 

Consider append(0, 0, 1) where the second position is the only bound output po- 
sition, as used in the programs in Fig. ^ in mode M2 and Fig. ^ in mode M2. The 
program for append has input selectability. 

Now consider append(/, /, O) where the output position is free, as used in the 
programs in Fig. ^ in mode Mi and Fig. ^ in mode Mi. The program for append 
has input selectability. Note that the block declaration for append is the one that is 



usually given ( |Hill fc Lloyd, 1994| ; [Liittringhaus-Kappel, 1993| ; [Marchiori fc Teusink, 
19991) . < 



The following is a corollary of Lemma 3.16 needed to prove Lemma 5.4 



Corollary 3.19 

Let P be a permutation robustly typed, input-linear program with input selectabil- 
ity, Q = ai,...,a„ a vr-robustly typed query and i,j £ {l,...,n} such that 
7r(i) < 7r(j). Let 



1 



1; ih 



, bi^i,B, bi+i, 



be a delay-respecting derivation and k G {1, . . . , m}, such that bk is a descendant 
of Ui and hi is a descendant of Uj. Then dom{9) H vars{bk) = 0- 

Proof 

Suppose that is p-robustly typed. By Cor. 3.4 we have p{k) < p{l). 

Suppose bi = pi{si,ti). 

Since 9 is obtained by unifying bi with a head of a clause C, and vars(C) Pi 
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:- block permute(-,-) . :- block delete(? ,- ,-) , 

permute ([],[]). delete (X , [X I Z] , Z) . 

permuteCUlX] ,Y) :- delete (X, [Ul Y] , [Ul Z] ) 

delete(U,Y,Z) , delete(X,Y,Z) . 

permute (X,Z) . 

Ml = {permute(/, 0),delete(/, 0,1)} 

M2 = {permute(0, /),delete(0, /, O)} 

Figure 5. Putting recursive calls last in the permute program 



vars{bi, . . . ,bm) = 0, it follows that domiO) C\ vars{bi, . . . ,bm) C vars{bi). By 
Lemma 3.16| , dom{9) n vars{si) — 0. Since bi, . . . ,bm is p-nicely moded, vars{bk) H 



varsiti) = and so dom{6) n vars{bk) — 9- □ 

Intuitively, the corollary says that if n{i) < 7r(j), then no aj-step will ever instan- 
tiate a descendent of a^. 

We conclude the section with a statement about permutation simply typed pro- 
grams, which we could not present earlier since it relies on the definition of input 
select ability. It says that in a derivation for a permutation simply typed program 
and query, it can be assumed without loss of generality that the output positions in 
each query are filled with variables that occur in the initial query or in some clause 
body used in the derivation. 

Corollary 3.20 

Let P be a permutation simply typed program with input selectability and Qq be 
a permutation simply typed query. Let Bq — 9 and ^ = {Qq, 9o)] (Qi, 0i); . . . be a 
delay-respecting derivation of P U {Qq}- Then for all i > 0, if a; is a variable in an 
output position in Qi, then x9i — x. 

Proof 

The proof is by induction on the position i in the derivation. The base case i — 
is trivial since 0o = 0- Now suppose the result holds for some i and Qi+i exists. 
By Lemma 3.11 (^), QjOj is permutation simply typed. Thus the result follows for 



J 1 by Lemma 3.11 (H). □ 



4 Termination and Speculative Bindings 



Like most approaches to the termination problem (De Schreye & Decorte, 1994), 
we are interested in ensuring that all derivations of a query are finite. Therefore the 
clause order in a program is irrelevant. Furthermore, we do not prove termination 
as such, but rather reduce the problem of proving termination for a program and 
query with left-based derivations to that with LD-derivations. 

In this section, we present two complementing methods of showing termination. 
These are explained in the following example. 



Example 4-1 
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Assuming left-based derivations, the program in Fig. ^loops for the query permute (V , [1] ) 



(hence, in mode M2) because delete produces a speculative output binding (Naish 



1992): The third argument of delete is bound before it is known that this binding 



will never have to be undone. Termination in modes Mi and M2 can be ensured 
by swapping the atoms in the second clause, as shown in Fig. ||. This technique 
has been described as putting recursive calls last (Naish, 1992). To explain why the 
program terminates, we have to apply a different reasoning for the different modes. 

In mode M2, the atom that produces the speculative output occurs textually 
before the atom that consumes it. This means that the consumer waits until the 
producer has completed (undone the speculative binding). The program does not 
use speculative bindings. In mode Mi, the program does not make speculative 
bindings. 

Note that termination for this example depends on left-based derivations, and 
thus any method that abstracts from the selection rule must fail. < 

The methods presented in this section can be used to prove that the programs in 
|5[ ^, and terminate, but they do not work for the programs in Figs. || 
They formalise previous heuristics ( Naish, 1985 ; Naish, 1992|) and rely on 
conditions that are easy to check. 




4.1 Termination by not Using Speculative Bindings 



In LD-derivations, speculative bindings are never used ( Naish, 1992 ). A left-based 
derivation is an LD-derivation, provided the leftmost atom in each query is always 



selectable. Hence by Lemma 3/7, we have the following proposition. 

Proposition 4-2 

Let Q be a well typed query and P a well typed program such that an atom is 
selectable in P whenever its input positions of non-variable type are non-variable. 
Then every left-based derivation of P U {Q} is an LD-derivation. 



We now give two examples of programs where by Proposition 4.2, we can use any 
method for LD-derivations to show termination for any well typed query. Note that 
the method of Sec. |^ is not applicable for the program in Ex. 4.4 (because it is is 
not permutation robustly typed). 

Example 4-3 

Consider the program in Fig. ^ with mode M2 and either of the types given in 
Ex. 3^. This program is well- typed. < 



Example 4-4 

Consider the version of delete(0,/, 0) given in Fig. ^. Assuming either of the 
types given in Ex. 3.6, this program is well typed. <1 



Regarding this subsection, one may wonder: what is the point in considering deriva- 
tions for programs with block declarations where in effect we show that those block 
declarations are redundant, that is, the program is executed left-to-right? However, 
one has to bear in mind that a program might also be used in another mode, and 
therefore, the block declarations may be necessary. 
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:- block delete (?,-,-) . 
delete (X, [X|Z] ,Z) . 

deleteCX, [U| [HIT]] , [U|Z]) :- delete (X, [H I T] ,Z) . 

Figure 6. Most specific version of delete(0, /, 0) 



4-2 Termination by not Making Speculative Bindings 

Some programs and queries liave tlie nice property tliat tliere cannot be any fail- 



ing derivations. Bossi and Cocco ( |1999[ ) liave identified a class of programs called 
noFD having this property. Non-speculative programs are similar, but there are two 
differences: the definition of noFD programs only allows for L_D-derivations, but on 
the other hand, the definition of non-speculative programs requires that the clause 
heads are input-linear. 

Definition 4-5 

[non-speculative] A program P is non-speculative if it is permutation simply 
typed and input-linear, and every simply typed atom using a predicate in P is 
unifiable with some clause head in P. < 



Example 4.6 

Both versions of the permute program (Figs. and with either type given in 
Ex. 3.6, are non-speculative in mode Mi. Every simply typed atom is unifiable 
with at least one clause head. Both versions are not non-speculative in mode M2, 
because delete (A, [] ,B) is not unifiable with any clause head. < 



Example 4- 

The program in Fig. ^ is non-speculative in mode M\. However it is not non- 
speculative in mode because it is not permutation simply typed, due to the 
non-variable term [Label I List] in an output position. <l 

A delay-respecting derivation for a non-speculative program P with input selectabil- 
ity and a permutation simply typed query cannot fail.[^ However it could still be 
infinite. The following theorem says that this can only happen if the simply typed 
program corresponding to P has an infinite LD-derivation for this query. 

Theorem 4.8 

Let P be a non-speculative program with input selectability and P' a simply typed 
program corresponding to P. Let Q be a permutation simply typed query and Q' 
a simply typed query corresponding to Q. If there is an infinite delay-respecting 
derivation of P U {Q}, then there is an infinite LD-derivation of P' U {Q'}. {Proof 
see Appendix) 



''' It can also not flounder ( 



;5maus, 1999). 
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:- block is_list(-). 
is_list( [] ) . 
is_list([X|Xs]) :- 

is_list(Ys) , 

equal_list(Xs,Ys) . 

Figure 7. The is_list program 



:- block equal_list (- , ?) . 
equal_list ([],[]). 
equal_list ( [X I Xs] , [X I Ys] ) : - 
equal_list (Xs , Ys) . 



Theorem 4.8 says that for non-speculative programs, the atom order in clause bodies 
is irrelevant for termination. 

Note that any program that uses tests cannot be non-speculative. In Fig. ^, 
assuming mode Mi, the atoms leq(X,C) and grt(X,C) are tests. These tests are 



exhaustive, that is, at least one of them succeeds (Bossi & Cocco, 1999). This 



Ruggieri, 1999) 



suggests a generalisation of non-speculative programs ( Pedreschi 
(see Sec. ||). 

We now give an example of a program for which termination can be shown using 
Thm. 4^ but not using the method of Sec. ^ (see also Ex. 5.11 ). 



Example 4-9 

Consider the program in Fig. |^, where the mode is {is_list(/), equaU.ist(/, 0)} 
and the type is {is_list(Zisi), equal_list(Zjsi, list)}. The program is permutation 
simply typed (the second clause is (2, l)-simply typed) and non-speculative, and all 
LD-derivations for the corresponding simply typed program terminate. Therefore all 
delay-respecting derivations of a permutation simply typed query and this program 
terminate. < 



5 Termination and Insufficient Input 

We will now present an alternative method for showing termination that overcomes 
some of the limitations of the methods presented in the previous section. In partic- 
ular, the methods can be used for the programs in Figs. § and ^ as well as Figs. || 
and 1^. In practice, we expect the method presented here to be more useful, al- 
though, as Figs, [g] and show, it does not subsume the method of the previous 
section. 

As explained in Ex. |4.l| , termination of permute(0, /) can be ensured by applying 
the heuristic of putting recursive calls last ( Naish, 1992| ). The following example 



however shows that even this version of permute(0, /) can cause a loop depending 
on how it is called within some other program. 

Example 5.1 

Figure ^ shows a program for the n-queens problem, which uses block declarations 
to implement the test-and-generate paradigm. With the mode Mi and the type 
T, the first clause is (1, 3, 2)-nicely moded and (1,3, 2)-well typed. Moreover, all 
left-based derivations for the query nqueens(4,Sol) terminate. 

However, if in the first clause, the atom order is changed by moving 
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:- block nqueens(-,?) . 
nqueens (N, Sol) :- 

sequence (N.Seq) , 

safe (Sol) , 

permute (Sol , Seq) . 

:- block sequence (-,?) . 
sequence (0, [] ) . 
sequence (N , [N I Seq] ) : - 

< N, 

Nl is N-1, 

sequence (Nl , Seq) . 



:- block saf e_aux(- , ? , ?) , saf e_aux(? ,- , ?) , 

saf e_aux(? , ? , -) . 

saf e_aux( [],_,_). 
safe_aux( [MiMs] ,Dist,N) :- 

no_diag(N,M,Dist) , 

Dist2 is Dist+1, 

safe_aux(Ms,Dist2,N) . 

:- block no_diag(- , ? , ?) , no_diag(? ,- , ?) . 
no_diag(N,M,Dist) :- 

Dist =\= N-M, 

Dist =\= M-N. 



: - block saf e (-) . 
safe([]). 
safe([M|Ns]) :- 

safe_aux(Ns,l,N) , 

saf e(Ns) . 



:- block permute (-,-) . 
permute ( [],[]). 
permute([U|X] ,Y) :- 

delete(U,Y,Z) , 

permute (X,Z) . 



:- block delete(?,-,-) . 
delete (X, [X|Z] ,Z) . 
delete(X, [U|Y] , [U|Z] ) :- 
delete(X,Y,Z) . 

Ml = {nqueens(/, O), sequence(/, O), saf e(/), permute(0, /),<(/, /), 
is(0, /), saf e_aux(/, /, /), no_diag(/, /, /), =\=(/, /)} 

M2 ~ {nqueens(0, /), sequence(0, /),permute(/, O), is(0, /), . . .} 
T — {nqueens(mf, iZ), sequence(mt, ii), saf e(i/), permute(ii, i/), 

<{int, int), is{int, int), saf e_aux(ii, int, int), no_diag(int, int, int), 
=\={int, int)} 



Figure 8. A program for n-queens 



sequence (N, Seq) to the end, then nqueens (4, Sol) loops. This is because resolv- 
ing sequence (4, Seq) with the second clause for sequence makes a binding (which 
is not speculative) that triggers the call permute (Sol , [4|T]). This call results in 
a loop. Note that [4 1 T] , although non- variable, is insufficiently instantiated for 
permute (Sol, [4 1 T] ) to be correctly typed in its input position: permute is called 
with insufficient input. <\ 

To ensure termination, each atom that may loop when called with insufficient input 
should be placed sufficiently late; all producers of input for that atom must occur 
textually earlier. This assumes left-based derivations. Note that this explains in par- 
ticular why in the recursive clause for permute, the recursive call should be placed 



last, and hence we are effectively refining the heuristic proposed by Naish (1992). 
Note also that in nicely and well moded programs, all atoms are placed sufficiently 
late in this sense. 

In the next subsection, we identify the robust predicates, which are predicates for 



which all delay-respecting derivations are finite. In Subsec. 5.2 , we prove termination 
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for programs where the atoms using non-robust predicates are selected "sufficiently 
late". 



5.1 Robust Predicates 

In this subsection, derivations are not required to be left-based. The statements 
hold for arbitrary delay-respecting derivations, and thus the textual position of an 
atom in a query is irrelevant. Therefore we can, for just this subsection, assume 
that the programs and queries are robustly typed (rather than just permutation 



robustly typed). This simplifies the notation. In Subsec. 5.2, we go back to allowing 
for arbitrary permutations. 

Definition 5.2 

[robust] Let P be a robustly typed, input-linear program with input selectability. 
A predicate p in P is robust if, for each robustly typed query p(s,t), any delay- 
respecting derivation of P U {p(s,t)} is finite. An atom is robust if its predicate 
is. < 

By definition, a delay-respecting derivation for a query consisting of one robust atom 
terminates. We will see shortly however that this extends to queries of arbitrary 
length. To prove this, we first need the following simple lemma. 

Lemma 5.3 

Let Q = pi(si,ti), . . . ,p„(s„,t„) be a robustly typed query. Then there exists a 
substitution a such that dom{a) — var.s{ti, . . . ,t„_i), and p„(s„,t„)cr is robustly 
typed. 

Proof 

Since Q is robustly typed and types are closed under instantiation, there ex- 
ists a substitution a such that dom{a) — wars(ti, . . . , t„_i), ran{a) — 0, and 
(ti, . . . ,t„_i)(T is correctly typed. 

Since Q is nicely moded, doni{(j) H vars{tn) — 0. Since ran[a) — 0, it follows 
that )a is nicely moded. 

Since Q is well typed, it follows by Def. ^ that p„(s„,t„)cr is well typed. 

Therefore, as Q is robustly typed and t„(T — t„, it follows that p„(s„,t„)cr is 
robustly typed. □ 

The following lemma says that a robust atom cannot proceed indefinitely unless it 
is repeatedly "fed" by some other atom. 

Lemma 5.4 

Let P be a robustly typed, input-linear program with input selectability and F, 6, H 
a robustly typed query where 6 is a robust atom. A delay-respecting derivation of 
PU {F, h, H} can have infinitely many 6-steps only if it has infinitely many a-steps, 
for some a ^ F. (Proof see Appendix) 



The following lemma is a consequence and states that the robust atoms in a query 
on their own cannot produce an infinite derivation. 
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Lemma 5.5 

Let P be a robustly typed, input-linear program with input selectability and Q a 
robustly typed query. A delay-respecting derivation of PU {Q} can be infinite only 
if there are infinitely many steps where a non-robust atom is resolved. 

Proof 

Let ^ be an infinite delay-respecting derivation of PU{Q}. Assume, for the purpose 
of deriving a contradiction, that ^ contains only finitely many steps where a non- 
robust atom is resolved. Then there exists an infinite suffix ^ of ^ containing no 
steps where a non-robust atom is resolved. Consider the first query Q of ^. Then 
there is at least one atom in Q that has infinitely many descendants. Let d be the 



leftmost of these atoms. Then as a is robust, we have a contradiction to Lemma 5.4 . 
□ 

Approaches to termination usually rely on measuring the size of the input in a query. 



We agree with Etalle et al. (1999) that it is reasonable to make this dependency 
explicit. This gives rise to the notion of moded level mapping^ which is an instance 
of level mapping introduced by Bezem ( 1993| ) and Cavedon (1989). Since we use 



well typed programs instead of well moded ones ( jEtalle et al., 19991 ), we have to 
generalise the concept further. 

In the following definition, Bj?^ denotes the set of atoms using predicates occur- 
ring in P, that are correctly typed in their input positions. 

Definition 5.6 

[moded typed level mapping] Let P be a program. A function |.| : Bp'^ — > IN is a 
moded typed level mapping if for each p(s,t) G Bp'*' 

• for any u, we have |p(s,t)| = |p(s, u)|. 

• for any substitution 6, |p(s,t)| = \p{s6,t)\. 

Thus the level of an atom in Bp'^ only depends on the terms in the input positions. 
Moreover, all instances of an atom in B^'' have the same level. Here our concept 
differs from moded level mappings. Also, our concept is defined for atoms in B^^ 
that are not necessarily ground, but this difference only concerns the presentation. 

Since we only consider moded typed level mappings, we will simply call them 
level mappings. 



For a G B^'°, \a\ is the level of a. < 



The following standard concept is widely used in the termination literature (Apt 



1997) 



Definition 5. 7 

[depends on] Let p, q be predicates in a program P. Then p refers to q if there is 
a clause in P with p in its head and q in its body, and p depends on q (written 
P 3 9) if {p, q) is in the reflexive, transitive closure of refers to. We write p □ g if 
p ^ q and q ^ p, and p « q if p □ g and q ^ p. 

Abusing notation, we shall also use the above symbols for atoms, where p{s, t) □ 
q(u,v) stands for p ^ q, and likewise for □ and «. Furthermore, we denote the 
equivalence class of a predicate p with respect to « as [p]~. O 
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The following concept is used to show robustness. 
Definition 5.8 

[well-recurrent] Let P be a program and |.| a level mapping. A clause C = h ^ B 
is well-recurrent (with respect to |.|) if, for every a in B such that a ^ h, and 
every substitution 9 such that a9, hO G Bp''^, we have \h9\ > \a9\. 

A program (set of clauses) is well-recurrent with respect to |.| if each clause 
is well- recurrent with respect to | . | . <l 



Well-recurrence resembles well- acceptability ( Etalle et at, 1999 ) in that only for 



atoms a K, h there has to be a decrease, and that it assumes moded level map- 



pings. It differs from well-acceptability, but also from delay-recurrence (Marchiori 
|fc Teusink, 1999 ), in that it does not refer to a model of the program. 



To show that a predicate p is robust, we assume that all predicates q with p Z\ q 
have already been shown to be robust. 

Lemma 5.9 

Let P be a robustly typed, input-linear program with input selectability and p a 
predicate in P. Suppose all predicates q with p Z\ q are robust, and all clauses 
defining predicates q £ [p\~ are well-recurrent with respect to some level mapping 
|.|. Then p is robust. [Proof see Appendix) 

Example 5.10 



We demonstrate for the program in Fig. g|, with mode Mi and type T, how Lemma 5^ 
is used.0 Given that the built-in =\= terminates, it follows that no_diag is robust. 
With the list length of the first argument of safe_aux as level mapping, the clauses 
defining saf e_aux are well-recurrent so that saf e_aux is robust. In a similar way, 
we can show that safe is robust. < 

Example 5.11 

Consider again Ex. 4.9. We conjecture that is_list is robust, but Lemma 5.9 can- 



not show this. While Ex. 4.£ is contrived, it suggests that the method of Subsec. 4.2 



might be useful whenever Lemma 5.9 fails to prove that a predicate is robust. On 



the other hand, one could envisage to improve the method for showing robustness. 



for example by exploiting information given by a model of the program ( Etalle et al 
19991). <\ 



5.2 Well Fed Programs 



As seen in Ex. b_A , there are predicates for which requiring delay-respecting deriva- 
tions is not sufficient for termination. In general, the selection rule must be taken 
into account. We assume left-based derivations. Consequently we now give up the 
assumption, made to simplify the notation, that the clauses and query are robustly 



* We assume that the built-ins used here meet the conditions of Def. 3.17. We will see in Sub- 
sec. 7.1 why this is a safe assumption. 
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typed, rather than just permutation robustly typed. AU statements from the previ- 
ous subsection generalise to permutation robustly typed in the obvious way. 
A safe position in a query is a position that is "sufficiently late" . 

Definition 5.12 

[safe position] For a permutation tt, i is a called safe position for tt if for all j, 
7r(j) < 7r(«) implies j < i. < 

Whenever we simply speak of an atom in a safe position, we mean that this atom 
occurs in a 7r-robustly typed query Q in the ith position and i is a safe position for 
TT, where Q and tt are clear from the context. 

The next lemma says that in a left-based derivation, atoms whose ancestors are 
all in safe positions can never be waiting (see Def. p^ ). 

Lemma 5.13 

Let P be a permutation robustly typed program with input selectability, Qo a 
permutation robustly typed query and ^ = Qq; . . .]Qi . . . a left-based derivation 
of P U {Qo}- Then no atom in Qi for which all ancestors are in safe positions is 
waiting. 

Proof 



Suppose Qi = ai, . . . , a„ is TTi-robustly typed (note that tt^ exists by Lemma 3.16) 



Let Ofc be an atom in Qi with all its ancestors in safe positions. By Def. 3.5, 0,^.-1(1) 
is correctly typed in its input positions and hence selectable. Moreover, since k is 
a safe position, 7ri^^(l) < k. It follows that if the proper ancestors of ak are not 
waiting, then Ofc is not waiting. 

The result follows by induction on i. When z = 0, has no proper ancestors 
and hence, by the above paragraph, au is not waiting. When i > 0, then all proper 
ancestors of are in safe positions (by hypothesis) and hence, by the inductive 
hypothesis, they are not waiting. Thus, by the above paragraph, is not waiting. 

□ 



To show Thm. 5.18| , we need the following corollary of Lemma 5.15 



Corollary 5.14 

Make the same assumptions as in Lemma 5.15 . If Qi = ai , . . . , a„ is TTi-robustly 
typed and the atom selected in QiiQi+i has only ancestors in safe positions, 
then ni{k) — 1 (and hence ak is correctly typed in its input positions). 

A permutation robustly typed query is called well fed if each atom is robust or in a 



safe position. Note that if a predicate p can be shown to be robust using Lemma 5.9 
then all predicates q with p Z\ q are also robust. However, this is a property of the 
method for showing robustness, not of robustness itself. To simplify the proof of 



Thm. 5.18, we want to exclude the pathological situation that p is robust but some 



predicate q with pZ\ qis not. 



Definition 5.15 
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[well fed] A tt- robustly typed query is well fed if for each of its atoms p{s, t), either 
p(s, t) is in a safe position for tt, or all predicates q with p ^ q are robust. A clause 
is well fed if its body is. A program P is well fed if all of its clauses are well fed 
and input-linear, and P has input selectability. < 

The following proposition is a direct consequence of the definition of the derived 



permutation (see Lemma 3.3) 



Proposition 5.16 

Let P and Q be a well fed program and query, and ^ a derivation of P U {Q}- 
Then each atom in each query in ^ is either robust, or all its ancestors are in safe 
positions. 

Example 5.17 

The program in Fig. ^ is well fed in both modes. The program in Fig. ^ is well fed 
in mode Mi. It is not well fed in mode M2, because it is not permutation nicely 
moded in this mode: in the second clause for sequence, Nl occurs twice in an output 
position. < 

The following theorem reduces the problem of showing termination of left-based 
derivations for a well fed program to showing termination of LD-derivations for a 
corresponding robustly typed program. 

Theorem 5.18 

Let P and Q be a well fed program and query, and P' and Q' a robustly typed 
program and query corresponding to P and Q. If every LD-derivation of P' U {Q'} 
is finite, then every left-based derivation of P U {Q} is finite. [Proof see Appendix) 

Given that for the programs of Figs. |[ || and ^, the corresponding robustly typed 
programs terminate for robustly typed queries, it follows by the above theorem that 
the original programs terminate for well fed queries. 

For the program of Fig. ^, our method can only show termination for the mode 
Ml, but not for M2, although the program actually terminates for M2 (provided 
the block declarations are modified to allow for M2). 



6 Freedom from Errors Related to Built-ins 

One problem with built-ins is that their implementation may not be written in 
Prolog. Thus, for the purposes of this paper, it is assumed that each built-in is 



conceptually defined by possibly infinitely many (fact) clauses (Sterling & Shapiro 



1986). For example, there could be facts "0 is 0+0.", "1 is 0+1.", and so forth. 

To prove that a program is free from errors related to built-ins, we require it to 
be permutation simply typed. This applies also to the conceptual clauses for the 
built-ins. 

Some built-ins produce an error if certain arguments have a wrong type, and 
others produce an error if certain arguments are insufficiently instantiated. For 
example, X is foo results in a type error and X is V results in an instantiation 
error. 
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The approach described here aims at preventing instantiation and type errors for 
buih-ins, for example arithmetic buih-ins, that require arguments to be ground. 



It has been proposed (Apt & Luitjes, 1995) that these predicates be equipped 



with delay declarations to ensure that they are only executed when the input is 
ground. This has the advantage that one can reason about arbitrary arithmetic 
expressions, say qsort ( [1+1,3-8] ,M). The disadvantage is that block declarations 
cannot be used. In contrast, we assume that the type of arithmetic built-ins is the 
constant type num, rather than arithmetic expressions. Then we show that block 
declarations are sufficient. The following lemma is similar to and based on Lemma 27 



( |Apt fc Luitjes, 1995|) 



Lemma 6.1 

Let Q — pi(si,ti), . . . ,p„(s„,t„) be a 7r-well typed query, where pi{Si,Ti) is the 
type of Pi for each z e {1, . . . , n}. Suppose, for some k G {1, . . . , n}, is a vector 
of constant types, Sfe is a vector of non-variable terms, and there is a substitution 
such that tjO : Tj for all j with 7r(j) < 7r(/c). Then Sk : Sj,. 

Proof 



By Def. s^^ : Sa,, and thus s^^ is a vector of constants. Since is already a 
vector of non-variable terms, it follows that Sk is a vector of constants and thus 
Sfe^ = Sfe. Therefore : S^. □ 



Note that if Sfc is of type Sfc, then Sfc is ground. By Def. |3.8| , for every permutation 



simply typed query Q, there is a ^ such that Q9 is correctly typed in its output 



positions. Thus by Lemma 6.1, if the arithmetic built-ins have type num in all 
input positions, then it is enough to have block declarations such that these built- 
ins are only selected when the input positions are non-variable. This is stated in 



the following theorem which is a consequence of Lemma 3.1 



Theorem 6.2 

Let P be a permutation simply typed, input-linear program with input selectability 
and Q be a permutation simply typed query. Let p be a predicate whose input po- 
sitions are all bound and of constant type. Then in any delay-respecting derivation 
of P U {Q}, an atom using p will be selected only when its input arguments are 
correctly typed. 

When we say that the input positions of a built-in are bound, we imply that the 
conceptual clause heads have non- variable terms in those positions. 

Example 6.3 

For the program in Fig. |^ in mode Mi , no delay-respecting derivation for a permu- 
tation simply typed query and this program can result in an instantiation or type 
error related to the arithmetic built-ins. 



7 block Declarations and Equality Tests 



Runtime testing for instantiation has an overhead, and in the case of built-ins, can 
only be realised by introducing an auxiliary predicate (see Fig. ^ . Therefore in the 
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following two subsections, we describe ways of simplifying the block declarations 
of a program. An additional benefit is that in some cases, we can even ensure that 



arguments are ground, rather than just non-variable. We will see in Subsec. 7.3 



that this is useful in order to weaken the restriction that every clause head must 
be input-linear. We have postponed these considerations so far in order to avoid 
making the main arguments of this paper unnecessarily complicated. 



7.1 Avoiding block Declarations for Permutation Simply Typed 

Programs 

In the program in Fig. |[ there are no block declarations and hence no auxiliary 
predicates for <, is and =\=. This is justified because the input for those predicates 
is always provided by the clause heads. For example, it is not necessary to have a 
block declaration for < because when an atom using sequence is called, the first 
argument of this atom is already ground. We show here how this intuition can be 
formalised. In the following definition, we consider a set B containing the predicates 
for which we want to omit the block declarations. 

Definition 7.1 

[S-ground] Let P be a permutation simply typed program and B a set of predicates 
whose input positions are all of constant type. 

A query is ;B-ground if it is permutation simply typed and each atom using a 
predicate in B has ground terms in its input positions. 

An argument position fc of a predicate p in P is a S-position if there is a clause 
p(to,s„_|_i) ^ pi(si,ti), . . . ,p„(s„,t„) in P such that for some i where pi € B, 
some variable in also occurs in position k in p(to,s„+i). 

The program P is ;B-ground if every ;B-position of every predicate in P is an 
input position of constant type, and an atom p{s, t), where p ^ B, is selectable only 
if it is non- variable in the S-positions of p. <l 

Note that since a constant type is, in particular, a non-variable type, it is always 
possible to find block declarations such that both the requirement on selectability 
in the above definition and in Def. 3.17| (||) are fulfilled. 



Example 7.2 

The program in Fig. ^ is ,B-ground, where B = {<, is, =\=}. The first position 

of sequence, the second position of saf e_aux, and all positions of no_diag are 

B-positions. < 

The following theorem says that for S-ground programs, the input of all atoms 
using predicates in B is always ground. 

Theorem 7.3 

Let P be a S-ground, input-linear program with input selectability, Q a i3-ground 
query, and ^ a delay- respecting derivation of P U {Q}. Then each query in ^ is 
B-ground. 



Proof 
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The proof is by induction on the length of ^. Let Qq = Q and ^ = Qq] Qi; . . .. The 
base case holds by the assumption that Qq is S-ground. 

Now consider some Qj where j > and Qj+i exists. By Lemma 3.11| (||), Qj 
and Qj+i are permutation simply typed and hence type-consistent in all argument 
positions. The induction hypothesis is that Qj is S-ground. 

Let p{u,v) be the selected atom, C — p(to,s„+i) ^ pi(si,ti), . . . ,p„(s„,t„) 
be the clause and 9 the MGU used in the step Qj\Qj+i- Consider an arbitrary 
i £ {1, . . . , n} such that pi G B. 

U p ^ B, then by the condition on selectability in Def. 7T, p{u, v) is non- variable 
in the ;B-positions of p and hence, since the ;B-positions are of constant type, p(u, v) 
is groundin the S-positions of p. If p G B, thenp(u, v) is ground in all input positions 
by the induction hypothesis, and hence p{u, v) is a fortiori ground in all S-positions 
of p. 

Thus it follows that Si6 is ground. Since the choice oii was arbitrary and because 
of the induction hypothesis, it follows that Qj+i is ;B-ground. □ 

In Thm. |7.3| , the assumption that the predicates in B have input selectability is 
redundant. Atoms using predicates in B are only selected when their input is ground, 
simply because their input is ground at all times during the execution. 

Example 7.4 

In the program in Fig. |8[ there are no block declarations, and hence no auxiliaries, 
for the occurrences of is, < and =\=, but there are block declarations on saf e_aux 
and no_diag that ensure the condition on selectability in Def. 7.1. < 



7.2 Simplifying the block Declarations Using Atoms in Safe Positions 

By a simple observation, we can simplify the block declarations for predicates that 
are only used in atoms occurring in safe positions. Consider a permutation robustly 
typed program P with input selectability and a permutation robustly typed query 
Q. Suppose we have a predicate p such that for all q with q ^ p, all atoms using q 
in Q and clause bodies in P are in safe positions. 



Then by Lemma 5.13, in any left-based derivation of P U {Q}, an atom using p 
is never waiting. Thus, the block declarations do not delay the selection of atoms 
using p. Suppose we modify P by replacing the block declaration for p with the 
empty block declaration. Then the modified program has the same set of left-based 
derivations of Q as the original program. For example, the block declaration for 
sequence in the program in Fig. can be omitted. 



7.3 Weakening Input- Linearity of Clause Heads 

The requirement that clause heads are input-linear is needed to show the persis- 
tence of permutation nicely-modedness (Lemma ^.3| ). This is analogous to the same 
statement restricted to nicely-modedness (Apt & Luitjes, 1995, Lemma 11). How- 
ever, the clause head does not have to be input-linear when the statement is further 
restricted to L£)-resolvents (Apt & Pellegrini, 1994, Lemma 5.3). The following ex- 
ample by Apt (personal communication) demonstrates this difference. 



28 



J.-G. Smaus, P. M. Hill and A. M. King 



Example 7.5 
Consider the program 

q(A). r(l). eq(A,A). 

where the mode is {q(/), r(0), eq(/, /)}. Note that eq/2 is equivalent to the built-in 
=/2. This program is nicely moded but not input-linear. The query 

q(X), r(Y), eq(X,Y) 

is nicely moded. The query q(X),r(X) is a resolvent of the above query, and it is 
not nicely moded. <l 

Requiring clause heads to be input-linear is undoubtedly a severe restriction. It 
means that it is not possible to check two input arguments for equality. However, 
this also indicates the reason why in the above example, resolving eq(X, Y) is harm- 
ful: eq is meant to be a check, clearly indicated by its mode eq(/,/), but in the 
given derivation step, it actually is not a check, since it binds variables. 



It is easy to see that Lemma 3.3 still holds if Def. 3.1 is weakened by allowing 
= to be used in mode =(/, /), provided atoms using = are only resolved when both 
arguments are ground. Resolving the permutation nicely moded query Qi, s=t,Q2 
selecting s=t, where s and t are ground, will yield the resolvent Qi,Q2, which is 
permutation nicely moded. 

The mode =(/, /) can be realised with a delay declaration such that an atom 
s=t is selected only when s and t are ground. In SICStus, this can be done using 
the built-in when ( ^ICStus, 1998| ). However we do not follow this line because this 
paper focuses on block declarations, and because it would commit a particular 
occurrence of s=t to be a test in all modes in which the program is used. 

Nevertheless, there are at least two situations when clause heads that are not 
input-linear can be allowed. First, one can exploit the fact that atoms are in safe 
positions, and secondly, that the arguments being checked for equality are of con- 
stant type. 

In the first case, we assume left-based derivations. We could allow for clause heads 
p{t,s) where a variable x occurs in several input positions, provided that 

• all occurrences of a; in t are in positions of ground type, and 

• for each clause body and initial query for the program, each atom using a 
predicate q with q □ p is in a safe position. 



By Cor. 5.14, it is then ensured that multiple occurrences of a variable in the input 



of a clause head implement an equality check between input arguments. Therefore, 



Lemmas 3.3, 3.11 and 3.1(; hold assuming this weaker definition of "input-linear" 



Example 7.6 

Consider the program in Fig. |^ in mode {permute(/, /), delete(/, /, /)}. This 
program is not input-linear. Nevertheless, the program can be used in this mode 
provided that all arguments are of ground type and calls to permute and delete 
are always in safe positions. <] 
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:- block length(-,-). 
length(L,N) :- 
len_aux(L,0,N) . 

:- block less(?,-), less(-,?). 
less(A,B) :- 
A < B. 

Figure 9. The length program 



:- block len_aux (?,-,?) , 
len_aux (-,?,-) . 

len_aux([] ,N,N) . 

len_aux([_|Xs] ,M,N) :- 
less(M,N) , 
M2 is M + 1, 
len_aux(Xs,M2,N) . 



In the second case, it is sufficient to assume delay-respecting derivations. We can 



use Thm. 6.2. This time, we have to allow for clause heads p{t, s) where a variable 



X occurs in several input positions, provided that 

• X only occurs directly and in positions of constant type in t, and 

• an atom using p is selectable only if these positions are non-variable. 

It is then ensured that when an atom p{u, v) is selected, u has constants in each 
position where t has x. 

Example 7. 7 

Consider the program shown in Fig. ^. It can be used in mode {length(0, /), 
len_aux(0, /, /)} (it is simply typed) in spite of the fact that len_aux([], N, N) is not 
input-linear, using either of the two explanations above. The first explanation relies 
on all atoms using predicates q □ len_aux being in safe positions. This is somewhat 
unsatisfactory since imposing such a restriction impedes modularity. Therefore, the 
second explanation is preferable. < 



8 Related Work 



First of all, note that our work implicitly relies on previous work on termination for 



LD-derivations ( Apt, 1997 ; De Schreyc fc Decorte, 1994 ), since we reduce the prob- 
lem of termination of a program with block declarations to the classical problem 
of termination for LD-derivations. 

In using modes and types, we follow Apt and Luitjes ( 1995| ), and also adopt 
their notation. They show occur-check freedom for nicely moded programs and non- 
floundering for well typed programs. For arithmetic built-ins they require delay 
declarations such that an atom is delayed until the arguments are ground. Such 
declarations are usually implemented not as efficiently as block declarations. For 
termination, they propose a method limited to deterministic programs. 

Naish ( 1992| ) gives good intuitive explanations (without proof) why programs 
loop, which directed our own search for further ideas and their formalisation. Pred- 
icates are assumed to have a single mode. It is suggested that alternative modes 
should be achieved by multiple versions of a predicate. This approach is quite com- 
mon (Apt & Etalle, 1993; Apt & Luitjes, 1995; Etalle et a/., 1999| ) and is also taken 



in Mercury (3omogyi et at, 199(;), where these versions are generated by the com- 
piler. While it is possible to take that approach, this is clearly a loss of generality 



30 



J.-G. Smaus, P. M. Hill and A. M. King 



since two different versions of a predicate is not the same thing as a single one 
which can be used in several modes. Naish uses examples where, under the above 
assumption, delay declarations are unnecessary. For permute, if we only consider 
the mode M2, then the program in Fig. ||does not loop simply because no atom is 
ever delayed, and thus the program behaves as if there were no delay declarations. 
In this case, the interpretation that one should "place recursive calls last" is mis- 
leading. If we only consider the mode Mi, then the version of Fig. ^ is much less 
efficient than Fig. 0. In short, his discussion on delay declarations lacks motivation 
when only one mode is assumed. 

Liittringhaus-Kappel (1992) proposes a method for generating control auto- 
matically, and has applied it successfully to many programs. However, rather than 
pursuing a formalisation of some intuitive understanding of why programs loop, 
and imposing appropriate restrictions on programs, he aims for a high degree of 
generality. This has certain disadvantages. 

The method only finds acceptable delay declarations, ensuring that the most 
general selectable atoms have finite SLD-trees. What is required however are safe 
delay declarations, ensuring that instances of most general selectable atoms have 
finite SLD-trees. A safe program is a program for which every acceptable delay 
declaration is safe. Liittringhaus-Kappel states that all programs he has considered 
are safe, but he gives no hint as to how this might be shown in general. 

The delay declarations for some programs such as quicksort require an argument 
to be a nil-terminated list before an atom can be selected. As Liittringhaus-Kappel 
points out, "in NU-Prolog [or SICStus] it is not possible to express such conditions". 
We have shown here that, with a knowledge of modes and types, block declarations 
are sufficient. 

Furthermore, the method assumes arbitrary delay-respecting derivations and 
hence does not work for programs where termination depends on derivations being 
left-based. 

Marchiori and Teusink ( 1999 ) base termination on norms and the covering 
relation between subqueries of a query. This is loosely related to well-typedness. 
However, their results are not comparable to ours because they assume a local 
selection rule, that is a rule that always selects an atom that was introduced in 
the most recent step. No existing language using a local selection rule (other than 
the LD selection rule) is mentioned, and we are not aware that there is one. The 
authors state that programs that do not use speculative bindings deserve further 
investigation, and that they expect any method for proving termination with full 
coroutining either to be very complex, or very restrictive in its applications. 

Martin and King (1997) ensure termination by imposing a depth bound on 
the SLD tree. This is realised by a program transformation introducing additional 
argument positions for each predicate, which are counters for the depth of the 
computation. The difficulty is of course to find an appropriate depth bound that 
does not compromise completeness. It is hard to compare their work to ours since 
they transform the programs substantially to obtain programs for which it is easier 
to reason about termination, whereas we show termination for much more "tradi- 
tional" programs. 
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Recently, Pedreschi and Ruggieri (1999) have shown that for programs that 
have no faihng derivations, termination is independent of the selection rule. They 
consider guarded clauses, and the execution model is such that the evaluation of 
guards is never considered as a failure. For example, even the quicksort program 
is non-failing in this sense, since the tests leq(X,C) and grt(X,C) (see Fig. |[) 
would be guards. In contrast to the method presented in Subsec. 4.2, they can 
show termination for this program. 

The verification methods used here can also be used to show that programs are 
free from (full) unification, occur-check, and floundering. These relatively straight 
forward generalisations of previous results ( Apt fc Etalle, 1993 ; Apt fc Luitjes, 1995 



Apt fc Pellegrini, 1994) are discussed in Smaus's PhD thesis (1999). 



9 Discussion and Future Work 

We have presented verification methods for programs with block declarations. The 
verified properties were termination and freedom from errors related to built-ins. 



These methods refine and formalise previous work in this area (Apt & Etalle, 1993 
Apt fc Luitjes, 1995| ; [Naish, 1992| ). 



In the introduction, we have said that this work has three distinctive features: (a) 
assuming multiple modes, (b) using block declarations, (c) formalising the "default 
left-to-right" selection rule. While the significance of (a) can be argued (see below), 
at least features (b) and (c) mean that we are addressing existing programs and 
existing language implementations. This is further strengthened by the fact that, 
using the results of Sec. ^ we can verify programs where only some of the predicates 
are equipped with block declarations. 

In the literature, we also find other types of delay declarations: In Godel ( [Hilj 
|fc Lloyd, 1994 ), delay declarations can test for non- variableness of sub-arguments 



up to a certain depth (e.g. DELAY P([x|xs]) UNTIL NONVAR(xs)) or for groundness of 
arguments; also, in theory, one can consider delay declarations that test arguments 
for being instantiated to a list or similar structure ( [Liittringhaus-Kappel, 1993| ). 
Most of our results require that an atom is selected only if certain arguments are 
at least non-variable, and so they trivially also hold for those delay declarations. 
On the other hand, the results in Subsec. require that an atom is definitely 
selectable whenever it is correctly typed in its input positions. We claim that this is 
a natural requirement which should also be fulfilled by most programs using other 
kinds of delay declarations, but to substantiate this claim, we would have to specify 
precisely the delay declarations and the underlying modes and types. 

For proving termination, we have presented two approaches. The first approach 
( ^maus et al.^ 19*99 ) consists of two complementing methods based on not using and 



not making speculative bindings, respectively. For Figs. ^ and |^, it turns out that 
in one mode, the first method applies, and in the other mode, the second method 
applies. This approach is simple to understand and to apply. However it is rather 
limited. Termination cannot be shown for the programs of Figs. |^ and ^. 



In the second approach (Smaus et ai, 1998), we required programs to be per 



mutation robustly typed, a condition that ensures that no call instantiates its own 
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input. In the next step, we identified when a predicate is robust, which means that 
every delay-respecting derivation for a query using the predicate terminates. Ro- 
bust atoms can be placed in clause bodies arbitrarily. Non-robust atoms must be 
placed such that their input is sufficiently instantiated when they are called. 

Concerning built-ins, we have shown that even though some built-ins require 
their input arguments to be ground, it is still sometimes sufficient to use block 
declarations. 

We have also considered how some of the block declarations can be omitted if 
it can be guaranteed that the instantiation tests they implement are redundant. 
This is useful because even for programs containing block declarations, it is rare 
that all predicates have block declarations. In particular, it is awkward having to 
introduce auxiliary predicates to implement delay declarations for built-ins. 

It is an ongoing discussion whether it is reasonable to assume predicates that 
work in several modes ( Hill, 1998 ). We have argued that a formalism dealing with 
delay declarations should at least allow for multiple modes. This does not exclude 
in any way other applications of delay declarations, such as implementing the test- 
and-generate paradigm (coroutining) . As seen in the program of Fig. |[ our results 
apply to such programs as well. 

The main purpose of this work is software development, and it is envisaged that 
an implementation should take the form of a program development tool. The pro- 
grammer would provide mode and type information for the predicates in the pro- 
gram. The tool would then generate the block declarations and try to reorder the 
atoms in clause bodies so that the mode and type requirements are met. Where 
applicable, finding the free and bound positions, as well as the level mapping used 
to prove robustness, should be done by the tool. 
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A Proofs 

Lemma |3.11 Let Q = pi(si,ti), . . . ,p„(s„,t„) be a 7r-simply typed query and 
C = pfc(vo,Um+i) ^ gi(ui,vi), . . . ,9,„(u,„,Vm) a p-simply typed, input-linear 
clause where vars{C) n vars{Q) = 0. Suppose that for some k G {!,... ,n}, Sk 
is non- variable in all bound input positions, and 9 is the MGU of pk{sk,tk) and 
Pfc(vo,u,„+i). Then 

1. there exist substitutions 9i, 02 such that 6 = 6162 and 

(a) vo^i ~ Sk and dom{9i) C wars(vo), 

(b) tfc02 = VLrn+iOi and dom{92) C vars{tk), 

2. dom(9) C vars(tk) U wars(vo), 



Verifying Termination and Error- Freedom of Logic Programs 



33 



3. dom{9) n vars{ti, . . . ,tfe_i, vi, . . . , v„,tfe+i, . . . ,t„) = 0, 

4. the resolvent of Q and C with selected atom pk{sk,tk) is p-simply typed, 



where g is the derived permutation (see Lemma 3.2) 



Proof 

By assumption is non- variable in all bound positions, and Vq is a linear vector 
having flat terms in all bound positions, and variables in all other positions. Thus 
there is a substitution 9i such that Vq^i = Sfc and dom{6i) C z;ars(vo), which 
shows (|Ta|). 

Since is a linear vector of variables, there is a substitution 62 such that 
dom{92) Q vars{tk) and tk02 — Um+16'1, which shows (|lb|). 

Since Q is 7r-nicely moded, vars{tk) n vars{sk) = 0, and therefore vars{tk) H 
vars (vo6li) = 0. Thus it follows by (0) that 9 = 6162 is a unifier of pk{sk,tk) and 
Pfc(vo, u„i-|_i). follows from ( p^ and ([lb|), and (||) follows from (|2|) because of 
linearity. 

By Lemma 3.3 and 3.7, the resolvent is g-nicely moded and g-weW typed. By (^, 



the vector of the output arguments of the resolvent is a linear vector of variables, 
and hence (0) follows. □ 



Lemma 3.16 Let Q = pi(si,ti), . . . ,p„(s„,t„) a 7r-robustly typed query and C = 
Pfe(vo, Um+i) <— gi(ui, vi), . . . , 9m(u,„, v„i) a p- robustly typed, input-linear clause 
where vars{Q) fl vars{C) — 0. Suppose that for some k e {!,... ,«}, pk{sk,tk) 
is non- variable in all bound input positions and is the MGU of Pfc(sfe,tfe) and 

J3fc(vo,U,„+i). 

Then the resolvent of Q and C with selected atom Pk{sk, t/c) is gi-robustly typed. 



where g is the derived permutation (see Lemma 3.3). Moreover dom{6) r\vars{sk) = 
0. 

Proof 

We show how 9 is computed, where we consider three stages. In the first, and Vq 
are unified. In the second, the output positions are unified where the bindings go 
from C to Q. In the third, the output positions are unified where the bindings go 



from Q to C. Figure A 1 illustrates which variables are bound in each stage. The 
first three parts of the proof correspond to the three stages of the unification. 

Part 1 (unifying Sfc and vq). By Def. 3.15 , vo is a vector of flat terms, where Vg is 



a vector of variables, and by assumption, vq is linear. By assumption, s^. is a vector 
of non-variable terms and, since vars{C) fl vars{Q) — 0, vars{wo) H vars{sk) — 0. 
Thus there is a (minimal) substitution 9i such that vq^^i = s^. We show that the 
following hold: 

(la) dom{9i) r\vars{sk) — 0- 

(lb) dom{9i) n wars(vi, . . . , v,„, ti, . . . ,t„) = 0. 

(Ic) Let X be a variable occurring directly in a position of type r in vl^-^j^^9i. 
Then x ^ vars{sk). Moreover, x can only occur in Vi, . . . , Vm,ti, . . . ,t„ in a 
bound position of type r, and the occurrence must be direct. 

(Id) vars{\im+iSi) n vars(tk) = 0. 
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Pfc(Sfc, tfc) 
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Pfc(vo, Um+l) 



'7i(ui,vi) 



Figure A 1 . Data flow in the unification 



(la) holds by the construction of 9i. 



(lb) holds since by Def. 3.13 and since C is input-linear, vq, . . . , v^^, t^, . . . , is 
linear. 

Let a; be a variable occurring directly in a position of type t in u^^_^_i9i. Let y 
be the variable in the same position in u^„_|_i. Suppose, for the purpose of deriving 
a contradiction, that y G wars(vo). Then by Def. 3.13| , y occurs directly in Vg, and 



since is a vector of non- variable terms, y9i is not a variable, which is a contradic- 
tion. Therefore y ^ vars{'Vo). Hence y ^ dom{Oi) and thus x — y and x ^ vars{sk)- 



Furthermore it follows by Def. 3.13 that x can only occur in vi, . . . , v,„, ti, . . . , t„ 
in a bound position of type r, and the occurrence must be direct. Thus (Ic) holds. 

Since Q is permutation nicely moded, vars{sk)C\vars{tk) — and hence ran{9i)C\ 
vars{tk) = 0. Thus (Id) holds. 

Part 2 (unifying and Um+iOi in each position where either the argument in tj, 
is a variable, or the arguments in and Um+iOi are both non- variable). Note that 
this includes all positions in and u^_,_]^0i, but may also include positions in 
and u^^j6'i. Since, by (lb), t^^i = t^. Part 2 covers precisely the output positions 



where the binding "goes from Um+i9i to tkOi' (see Fig. Al). We denote by t*^"*" 



k 



the projection of onto the positions where the argument in tk is a variable, or 
the arguments in and u^-i-i^i are both non- variable, and by the projection 
onto the other positions, and likewise for Um+iOi. 

By (Id), vars{u^j^_^_^di) n vars{t^i^) — 0. Thus there is a minimal substitution 6' 
such that t^+e' = ul+^^Oi. Let 6*2 = 910'. Then by (lb), t[+6l2 = We show 

the following: 



(2a) dom{62) Civars{sk) = 9- 

' - - - 

Then x ^ vars{sk). Moreover, x can only occur in vi, . . . ,Vm, ti, . . . ,tfc_i, 
t^~, tfe+i, . . . ,t„ in a bound position of type r, and the occurrence must be 
direct. 



(2b) dom{e2)r\vars{-Vi,...,Vm,ti,...,tk-i,tl , tfe+i, . . . , t„) = 0. 
(2c) Let X be a variable occurring directly in a position of type r in 



(2d) vars{um+i92) n vars{t'l ) = 0. 

Since vars{sk) n vars(tk) = 0, dom{6') n vars{sk) = 0. This and (la) imply (2a). 
(2b) holds because (lb) holds and vi, . . . , v„i, ti, . . . , t„ is linear. 



Furthermore, because of the hnearity of t^, (2d) follows 



By (Id), dom{9') n wars (u„_,.i 6*1) = 0. This together with (Ic) implies (2c). 
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Part 3 (unifying and u,^,7+i6'2). By (Id), dom{e')n vars{Ujj^^^9i) — 0, and thus 
u^2^2 = u^j^^i. Therefore, by the definition of the superscript b— in Part 2, 
u^2^2 is a vector of variables. By (2d), vars{u^_^-^92) fl vars{t'l^) = 0, so that 
there is a minimal substitution 9" such that u^_^-^929" = t^^. Let 6*3 = 929" . Then, 

t>- _ +t>-^ oT,^,,, /QnA 



by (2b), we have uj^^^^a = 03. We show (3a) and (3b) 



(3a) dom{93) rivars{sk) ~ 9- 

(3b) (vi, . . . , Vm, ti, . . . , t/j_i, t/j+i, . . . , 1,1)6*3 is linear and has flat type-consistent 
terms in all bound positions and variables in all free positions. 

By (2c), dom{9") r\vars{su) = 0. This and (2a) imply (3a). 

Suppose a; is a variable in u^^]^02 occurring in a position i of type r, and 
X also occurs in Vi, . . . , v^jti, . . . ,tfc_i,tfe+i, . . . ,t„. By (2c), the latter occur- 
rence of x is in a bound position of type r, and is the only occurrence of x in 
Vi, . . . , Vm, ti, . . . , tfe_i, tfc+i, . . . . t„. Let / be the set of positions where x oc- 
curs in u^j^02, and let T be the set of terms occurring in t^^ in positions in 
/. Then T is a set of variable-disjoint, flat terms. Therefore their most general 
common instance x9" is a flat term and x9" is type-consistent with respect to 
T. Moreover, since (vi, . . . , v^, ti, . . . , tfc_i, t^^, t^+i, . . . , t„) is linear, we have 
vars{x9") n tiars(vi, . . . , v^, ti, . . . , tk-i,tk+i, ■ ■ ■ , tn) = and therefore it follows 
that (vi, . . . , v,„,ti, . . . ,tfe„i,tfe+i, . . . ,tn)9" is a linear vector of type-consistent 
terms. This and (2b) imply (3b). 

Part 4: Defining = 6*3 it follows that pk{sk,tk)9 — pk{vo,Um+i)9. By (3b) and 



Lemmas 3.3 and 3.7, the resolvent of Q and C is g-robustly typed. By (3a), we have 



Sk9 = Sk. □ 



Theorem 4.8 Let P be a non-speculative program with input selectability and 
P' a simply typed program corresponding to P. Let Q be a permutation simply 
typed query and Q' a simply typed query corresponding to Q. If there is an infinite 
delay-respecting derivation of P U {Q}, then there is an infinite LD-derivation of 
P'U{Q'}. 

Proof 

For simplicity assume that Q and each clause body do not contain two identical 
atoms. Let Qq = Q, 9o = (d and ^ = (Q07 ^0); (Qi, ^1); ■ • ■ be a delay-respecting 
derivation of P U {Q}- The idea is to construct an LD-derivation of P' U {Q'} 
such that whenever ^ uses a clause C, then ^' uses the corresponding clause C" in 
P'. It will then turn out that if ^' is finite, ^ must also be finite. 

We call an atom a resolved in ^ at Hf a occurs in Qi but not in Qi+i- We call 
a resolved in ^ if for some i, a is resolved in <^ at i. Let Q'q = Q' and 9'^ = %. We 
construct an LD-derivation ^' — (Qg, 9'q); {Q'i,9'i); . . . of P' U {Q'} showing that for 
each i > the following hold: 

(1) If g(u, v) is an atom in Q'^ that is not resolved in ^, then vars{v9'j)r\dom{9j) — 
for aU j > 0. 

(2) Let a; be a variable such that, for some j > 0, x9j — /(. . .). Then x9'^ is either 
a variable or x9[ = /(. . .). 



36 



J.-G. Smaus, P. M. Hill and A. M. King 



We first show these properties for i = Q. Let q{u, v) be an atom in Qq that is not 
resolved in f . Since 9q = 0, v0q = v. Furthermore, by Cor. 3.12] and Cor. 3.20| and 
since g(u, v) is not resolved in ^, we have vdj = v for all j. Thus (1) holds. (2) 
holds because 9'^ = %. 

Now assume that for some j, {Q[,9[) is defined, Q[ is not empty, and (1) and 
(2) hold. Let p(s,t) be the leftmost atom of Q[. We define a derivation step 
{QiT^'il'i {Q'i+n^'i+i) ^^^^ P(s,t) as the selected atom, and show that (1) and (2) 
hold for {Q[+,A+i)- 

Case 1: p(s,t) is resolved in ^ at I for some /. Consider the simply typed clause 
C ~ h ^ B' corresponding to the uniquely renamed clause (using the same re- 
naming) used in ^ to resolve p(s,t). Since p(s,t) is resolved in ^ at I, p{s,t)9i is 
non- variable in all bound input positions. Thus each bound input position of p(s,t) 
must be filled by a non- variable term or a variable x such that x9i = /(...) for some 
/. Moreover, p{s,t)9[ must have non-variable terms in all bound input positions 
since Q'i9[ is well typed. Thus it follows by (2) that in each bound input position, 
p{s,t)9^ has the same top-level functor as p{s,t)9i, and since h has flat terms in 
the bound input positions, there is an MGU (p'^ of p{s, t)6'^ and h. We use C for 
the step (O^,0^);(g',+i,0^+i). 

We must show that (1) and (2) hold for i + 1. Consider an atom g(u, v) in Q[ 



other thanp(s, t). By Lemma 3.11 (|3|), vars{v9[)ndom{(l)'^) = 0. Thus for the atoms 
in Q'i^i that occur already in (1) is maintained. Now consider an atom q{u,'v) 
in B' that is not resolved in ^. By Cor. 3.2C, ^9'^^-^ = v. Since q{u, v) is not resolved 



in ^, for all j > I we have that q{u, v) occurs in Qj and thus by Cor. 3.20, v9j — v 



Thus (1) follows. (2) holds since it holds for i and p(s, t) is resolved using the same 
clause head as in ^. 

Case 2: p{s, t) is not resolved in ^. Since P' is non-speculative, there is a 
(uniquely renamed) clause C — h ^ B' va P' such that h and p(s, t)9[ have 
an MGU 0^. We use C for the step {Q[, 9[)- {Q[+^,9[^^). 

We must show that (1) and (2) hold for i + \. Consider an atom (7(u,v) in Q'^ 



other thanp(s,t). By Lemma 3.11 (|3|), vars{\-9[)C\dom{(j)[) = 0. Thus for the atoms 
in Q[j^i that occur already in Q^, (1) is maintained. Now consider an atom q{\i,v) 
in B' . Clearly q{u,-v) is not resolved in ^. Since vars{C') n vars{Qj9j) — for all 
j and since by Cor. 3.2C , we have v^^^;^ = v, (1) holds for i + 1. 

By (1) for i, we have vars{t9'^) n dom{9j) — for all j. By Lemma ^.11 (||), we 
have dora{4)'j) C vars{t9[) U vars{C'). Thus we have dom{(t)'^) D dom{9j) — for all 
j. Moreover, (2) holds for i. Thus (2) holds for i + 1. 

Since this construction can only terminate when the query is empty, either 
is empty for some n, or ^' is infinite. 

Thus we show that if ^' is finite, then every atom resolved in ^ is also resolved in 
So let ^' be finite of length n. Assume for the sake of deriving a contradiction 
that j is the smallest number such that the atom a selected in (Qj, 9j); (Qj+i, 0j+i) 
is never selected in Then j ^ since Qq and Q'q are permutations of each other 
and all atoms in Q'q are eventually selected in Thus there must be a fc < j such 
that a does not occur in Qk but does occur in Qk+i- Consider the atom b selected 
in {Qk,9k); {Qk+i,9k+i)- Then by the assumption that j was minimal, b must be 
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the selected atom in (Q-,^-); {Q'^^i , 9'^_^_i) for some i < n. Hence a must occur in 
Q'i^i, since the clause used to resolve b in ^' is a simply typed clause corresponding 
to the clause used to resolve b in i^. Thus a must occur in Q^, contradicting that ^' 
terminates with the empty query. 

Thus ^ can only be infinite if ^' is also infinite. □ 



Lemma 5^ Let P be a robustly typed, input-linear program with input selectabil- 
ity and F,b,H a, robustly typed query where 6 is a robust atom. A delay-respecting 
derivation of P U {-F, 6, i?} can have infinitely many 6-steps only if it has infinitely 
many a-steps, for some a G P. 

Proof 

In this proof, by an F-step we mean an a-step, for some a € F; likewise we define 
an H-step. By Cor. | .19|, no H-step can instantiate any descendant of F or b. 



Thus the 7J-steps can be disregarded, and without loss of generality, we assume H 
is empty. Suppose ^ is a delay-respecting derivation for P U {F, b} containing only 
finitely many P-steps. 

All F-steps are contained in a finite prefix of ^. Moreover, by Cor. ^.19 , no b- 



step can instantiate any descendant of F. Therefore, we can repeatedly apply the 
Switching Lemma (Lloyd, 1987, Lemma 9.1) to this prefix of ^ to obtain a delay- 
respecting derivation 

6 = (FA 0);...;(F',6, 

such that (F,6, 0); . . . ; (F',6, p) contains only F-steps and (F',6, p);^' contains 
only 6-steps. Now construct the delay-respecting derivation 

by removing the prefix F' in each query in (F',6, p);^'. 



By Lemma 3.16, {F',b)p is robustly typed. Thus by Lemma 5.3, there exists a 
substitution a such that bpa is robustly typed, and dom{a) = V , where V is the 
set of variables occurring in the output arguments of F' p. 



By Cor. 3.1£, no 6-step in ^2, and hence no derivation step in ^3, can instantiate 
a variable in V . Since dom{a) = V, it thus follows that we can construct a delay- 
respecting derivation 

^4 = {b,pa)\(,'^a 
by applying a to each query in ^3. 

Since bpa is a robustly typed query and 6 is robust, ^4 is finite. Therefore ^3, ^2, 
and finally ^ arc finite. □ 



Lemma |5.g| Let P be a robustly typed, input-linear program with input selectabil- 
ity and p a predicate in P. Suppose all predicates q with pZ\ q are robust, and all 
clauses defining predicates g G are well- recurrent with respect to some level 
mapping |.|. Then p is robust. 

Proof 

If a is an atom using a predicate in \p]~ such that the set S = {\a9\ \ aO ^ Bp''} 
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is non-empty and bounded, we define ||a|| = sup{S). Thus, for each atom a and 
substitution 9 such that ||a|| and \ \a6\\ are defined 

106*11 <||a|| (Al) 

To measure the size of a query, we use the multiset containing the level of each 
atom whose predicate is in The multiset is formalised as a function Size, 

which takes as arguments a query and a natural number: 

Size(Q){n) = #{g(u,v) | q(u,v) £ Q, q^p and ||g(u,v)|| = n}. 

Note that if a query contains several identical atoms, each occurrence must be 
counted. We define Size{Q) < Size{R) if and only if there is Z £ IN such that 
Size{Q){l) < Size{R){l) and Size{Q){l') = Size{R){l') for all V > I. Intuitively, 
there is a decrease when an atom in a query is replaced with a finite number of 



smaller atoms. All descending chains with respect to < are finite (Dcrshowitz, 1987) 



Let Qo = J'(s,t) be a robustly typed query. Then p(s,t) G Bp''' and thus ||Qo|| 
is defined. Let ^ = Qq] Qi; ... be a delay-respecting derivation of P U {Qq}- 

Since all predicates q with pZ\ q are robust, it follows by Lemma [sTs] that there 
cannot be an infinite suffix of ^ without any steps where an atom (7(u, v) such that 
g « p is resolved. We show that for all z > 0, if the selected atom in Qi\Qi+i 
is (7(u, v) and q ~ p, then Size{Qi+i) < Size{Qi), and otherwise Size{Qi+i) < 
Size{Qi). This implies that ^ is finite, and, as the choice of the initial query Qq — 
p(s,t) was arbitrary, p is robust. 



By Lemma 3.16, each position in each atom in Qi+i is filled with a type-consistent 
term. (*) 

Consider i > and let C = q(vo,Um+i) <— gi(ui, vi), . . . , (7m(um, v™) be the 
clause, q{u,v) the selected atom and 9 the MGU used in Qi;Qi+i. 



If p □ g, then p □ qj for all j G {1, . . . , m}, and hence by ( Al) and (*) it follows 
that Size{Qi^i) < Size{Qi). Intuitively, the set of atoms that are measured by 
Size does not change in this step (although the level of each atom might decrease). 

Now consider q k, p. Since C is well-recurrent and because of (*), we have 



||(7(vo, Um+i)0|| > \\qj{u.j,^^j)9\\ for all j with qj « p. This together with ( |A l[ ) 
implies Size{Qi+i) < Size{Qi). Intuitively, one atom has been replaced by smaller 
atoms in this step, but apart from that, the set of atoms that are measured by Size 
does not change. □ 



Theorem 5.18 Let P and Q be a well fed program and query, and P' and Q' a 
robustly typed program and query corresponding to P and Q. If every LD-derivation 
of P' U {Q'} is finite, then every left-based derivation of P U {Q} is finite. 

Proof 

Suppose there is an infinite left-based derivation ^ of PU{Q}. Then letting Qo = Q, 
^0 = 0, we can write 

C = (Qo, 0o); . . . ; (i?i, fTi); {Qi,9i); . . . ; (i?2, (T2); (Qa, ^2) • . . 

where i?i,i?2,-- - are the queries in ^ where a non- robust atom is selected. By 
Lemma |5.5|, there are infinitely many such queries. We derive a contradiction. 
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By Prop. |3.16 , the non-robust atoms in each query in ^ have only ancestors in 
safe positions. Thus by Cor. 5.14, for each i > 1, where Ri is pi-i'obustly typed, the 
Pi^^(l)'th atom in Ri is selected in {Ri,ai)- {Qi,9i). 

Now consider an arbitrary query Q in ^ and assume it is Tf-robustly typed. By 



Cor. 3.4 and the previous paragraph it follows that there exists a query in ^ that 
contains no descendants of the 7i"^^(l)'th atom Q. Intuitively, for each query in 
the atom that is "leftmost according to its permutation" will eventually be resolved 
completely. 

By repeatedly applying the Switching Lemma to prefixes of ^, we can construct 
a derivation C of P U {Q} such that in each query Q in that is 7r-robustly typed, 
the #~^(l)'th atom is selected using the same clause (copy) used in ^. Note that 
this construction is possible by the previous paragraph. Also note that ^ is infinite. 

Now consider the derivation C obtained from ( by replacing each 7r-robustly typed 
query Q with Tr{Q), i.e. the robustly typed query corresponding to Q. The derivation 

is an LD-derivation of P' U {Q'}, and it is infinite. This is a contradiction. □ 



References 

Apt, K. R. (1997). From logic programming to Prolog. Prentice Hall. 

Apt, K. R., & Etalle, S. (1993). On the unification free Prolog programs. Pages 1-19 of: 
Borzyszkowski, A., & Sokolowski, S. (eds), Proceedings of the conference on mathemat- 
ical foundations of computer science. LNCS. Berlin: Springer- Verlag. 

Apt, K. R., & Luitjes, I. (1995). Verification of logic programs with delay declarations. 
Pages 66-90 of: Alagar, V. S., & Nivat, M. (eds). Proceedings of amast'95. LNCS. 
Berlin: Springer- Verlag. Invited Lecture. 

Apt, K. R., & Pellegrini, A. (1994). On the occur-check free Prolog programs. Acm 
transactions on programming languages and systems, 16(3), 687-726. 

Bezem, M. (1993). Strong termination of logic programs. Journal of logic programming, 
15(1 & 2), 79-97. 

Bossi, A., & Cocco, N. (1999). Successes in logic programs. Pages 219-239 of: Flener, 
P. (ed). Proceedings of the 8th international workshop on logic program synthesis and 
transformation. LNCS. Springer- Verlag. 

Boye, J. (1996). Directional types in logic programming. Ph.D. thesis, Linkopings Univer- 
sitet. 

Bronsard, F., Lakshman, T. K., & Reddy, U. S. (1992). A framework of directionality for 
proving termination of logic programs. Pages 321-335 of: Apt, K. R. (ed), Proceedings 
of the 9th joint international conference and symposium on logic programming. MIT 
Press. 

Cavedon, L. (1989). Continuity, consistency and completeness properties for logic pro- 
grams. Pages 571-584 of: Levi, C, & Martelli, M. (eds). Proceedings of the 6th inter- 
national conference on logic programming. MIT Press. 

De Schreye, D., & Decorte, S. (1994). Termination of logic programs: The never-ending 
story. Journal of logic programming, 19/20, 199-260. 

Deransart, P., & Maluszyriski, J. (1998). Towards soft typing for CLP. Pages, Frangois 
(ed), Jicslp '98 post-conference workshop on types for constraint logic programming. Ecole 
Normale Superieure. Available at http://discipl.inria.fr/TCLP98/. 

Dershowitz, N. (1987). Termination of rewriting. Journal of symbolic computation, 3(1 & 
2), 69-115. Corrigendum 4(3), 409-410. 



40 



J.-G. Smaus, P. M. Hill and A. M. King 



Etalle, S., Bossi, A., & Cocco, N. (1999). Termination of well-moded programs. Journal 
of logic programming^ 38(2), 243-257. 

Hill, P. M. (ed). 1998 (February). ALP Newsletter. Pages 17,18. 

Hill, P. M., & Lloyd, J. W. (1994). The Gddel Programming Language. MIT Press. 

Lloyd, J. W. (1987). Foundations of logic programming. Springer- Verlag. 

Liittringhaus-Kappcl, S. (1993). Control generation for logic programs. Pages 478-495 of: 
Warren, D. S. (ed). Proceedings of the 10th international conference on logic program- 
ming. MIT Press. 

Marchiori, E., & Teusink, F. (1999). Termination of logic programs with delay declarations. 

Journal of logic programming, 39(1-3), 95-124. 
Martin, J. C, & King, A. M. (1997). Generating efficient, terminating logic programs. 

Pages 273-284 of: Bidoit, M., & Dauchet, M. (eds). Proceedings of tapsoft'97. LNCS. 

Springer- Verlag. 

Naish, L. (1985). Automatic control of logic programs. Journal of logic programming, 
2(3), 167-183. 

Naish, L. (1992). Coroutining and the construction of terminating logic programs. Tech. 

rept. 92/5. University of Melbourne. 
Pedreschi, D., & Ruggicri, S. (1999). On logic programs that do not fail. Etalle, S., & 

Smaus, J.-G. (eds). Proceedings of the workshop on verification, organised within iclp'99. 

Electronic Notes in Theoretical Computer Science, vol. 30, no. 1. Elsevier. 
SICStus. (1998). SICStus Prolog User's manual. Intelligent Systems Laboratory, 

Swedish Institute of Computer Science, PO Box 1263, S-164 29 Kista, Sweden. 

http : //www . sics . se/ sicstus/ d.ocs/3 . 7 . 1/html/ sicstus_toc . html. 
Smaus, J.-G. (1999). Modes and types in logic programming. 

Ph.D. thesis. University of Kent at Canterbury. Available from 

www . cs .uic . ac.uk/people/staff/jgs5/thesis.ps. 
Smaus, J.-G., Hill, P. M., & King, A. M. (1998). Termination of logic programs with 

block declarations running in several modes. Pages 73-88 of: Palamidessi, C. (ed). 

Proceedings of the 10th symposium, on programming language implementations and logic 

programming. LNCS. Springer- Verlag. 
Smaus, J.-G., Hill, P. M., & King, A. M. (1999). Preventing instantiation errors and loops 

for logic programs with multiple modes using block declarations. Pages 289-307 of: 

Flener, P. (ed). Proceedings of the 8th international workshop on logic-based program 

synthesis and transformation. LNCS. Springer- Verlag. 
Somogyi, Z., Henderson, F., & Conway, T. (1996). The execution algorithm of Mercury, an 

efficient purely declarative logic programming language. Journal of logic programming, 

29(1-3), 17-64. 

Sterling, L., & Shapiro, E. (1986). The art of Prolog. MIT Press. 



